Solaris

Hi Gurus,

An application is failing to start when initiated in one of my sun boxes(Sol-5.10 Sparc).
A lot of core dumps got generated.
The debug of one of them is put below:

Code:

  (dbx) run
Running: shccmd
(process id 17831)
Reading libc_psr.so.1
Reading libmp.so.2
Reading libscf.so.1
Reading libdoor.so.1
Reading libuutil.so.1
Reading libmd_psr.so.1
t@1 (l@1) signal SEGV (no mapping at the fault address) in shc_init at line 107 in file "shc_wrapper.cxx"
  107           return( shcApp->shcHelperObj->shc_init() );
(dbx)

Its failing at the below call in dbx.

I checked the "libmd_psr.so.1" in the system and found it in shape.

I checked the size of this file in this server and another sparc server and found them different. I copied the "libmd_psr.so.1" file from the other server and moved it here and started the App,but the same result.

How should i proceed? Is it an App-end issue or a lib issue? How can i check that?

HG

use truss command to debug

Can you elaborate?

HG

Code:

truss /yourpath/application

The out put can help you debug whats the issue is? For more details of truss check the man pages.

Hi Gurus,

Reading libmd_psr.so.1
t@1 (l@1) signal SEGV (no mapping at the fault address) in shc_init at line 107 in file "shc_wrapper.cxx"
107 return( shcApp->shcHelperObj->shc_init() );

Does this mean that line 107 in file shc_wrpper.cxx file needs to be checked? (shc_init is the process that brings up the application and "shc" is the one among the many binaries that run the application.)

Hi amit,

I tried runing a truss,but the output was not understandable. Thanks for the tip. Will keep working on it.

HG

HG

The loading of the shared objects probably have nothing to do with your SEGV.

What does "pstack core" show? Have you ran your process under a dbx with run-time memory checking enabled?