From: Raxit on
Hi,


any clue for below dump ? same code working on other machine fine.
Any machine/ OS specific stuff. ?

bash$uname -a
SunOS <host name> 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-
Fire-880

(gdb) info threads
* 1 process 73221 0xff3bf430 in rtld_db_dlactivity () from /lib/
ld.so.1

(gdb) where
#0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1
#1 0xff3bf5f0 in rd_event () from /lib/ld.so.1
#2 0xff3b438c in relocate_lmc () from /lib/ld.so.1
#3 0xff3c5230 in dlmopen_core () from /lib/ld.so.1
#4 0xff3c52d0 in dlmopen_intn () from /lib/ld.so.1
#5 0xff3c547c in dlmopen_check () from /lib/ld.so.1
#6 0xff3c54f0 in dlopen () from /lib/ld.so.1
#7 0x00029290 in load_passwd_gen_dll () at <source code detail
deleted>
#8 0x0001bbb8 in initialise_server () at <source code detail deleted>
#9 0x0001a664 in main (argc=1, argv=0xffbffaec) at <source code
detail deleted>


-Raxit
From: Jens Thoms Toerring on
Raxit(a)mykavita.com <raxitsheth2000(a)gmail.com> wrote:
> any clue for below dump ? same code working on other machine fine.
> Any machine/ OS specific stuff. ?

> bash$uname -a
> SunOS <host name> 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-
> Fire-880

> (gdb) info threads
> * 1 process 73221 0xff3bf430 in rtld_db_dlactivity () from /lib/
> ld.so.1

> (gdb) where
> #0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1
> #1 0xff3bf5f0 in rd_event () from /lib/ld.so.1
> #2 0xff3b438c in relocate_lmc () from /lib/ld.so.1
> #3 0xff3c5230 in dlmopen_core () from /lib/ld.so.1
> #4 0xff3c52d0 in dlmopen_intn () from /lib/ld.so.1
> #5 0xff3c547c in dlmopen_check () from /lib/ld.so.1
> #6 0xff3c54f0 in dlopen () from /lib/ld.so.1
> #7 0x00029290 in load_passwd_gen_dll () at <source code detail
> deleted>
> #8 0x0001bbb8 in initialise_server () at <source code detail deleted>
> #9 0x0001a664 in main (argc=1, argv=0xffbffaec) at <source code
> detail deleted>

Just from the backtrace I guess nobody will be able to figure
out what's going on. But let's start with the probably reason-
able assumption that the internal code of dlopen() etc. is ok.
But it crashes in there. Then the most probable explanation is
that you have some memory corruption going on in your program
that leads to critical data needed by dlopen() getting overwrit-
ten with junk. That it did seem to work on a different system
does prove nothing, chances are that you were unlucky enough
that on the other system the layout in memory was different
and you just wrote over memory that wasn't relevant, at least
not for dlopen(), so it didn't crash already there.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt(a)toerring.de
\__________________________ http://toerring.de
From: Raxit on
On Jul 4, 6:11 pm, j...(a)toerring.de (Jens Thoms Toerring) wrote:
> Ra...(a)mykavita.com <raxitsheth2...(a)gmail.com> wrote:
> > any clue for below dump  ?  same code working on other machine fine..
> > Any machine/ OS specific stuff. ?
> > bash$uname  -a
> > SunOS <host name>  5.10 Generic_118833-36 sun4u sparc SUNW,Sun-
> > Fire-880
> > (gdb) info threads
> > * 1 process 73221      0xff3bf430 in rtld_db_dlactivity () from /lib/
> > ld.so.1
> > (gdb) where
> > #0  0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1
> > #1  0xff3bf5f0 in rd_event () from /lib/ld.so.1
> > #2  0xff3b438c in relocate_lmc () from /lib/ld.so.1
> > #3  0xff3c5230 in dlmopen_core () from /lib/ld.so.1
> > #4  0xff3c52d0 in dlmopen_intn () from /lib/ld.so.1
> > #5  0xff3c547c in dlmopen_check () from /lib/ld.so.1
> > #6  0xff3c54f0 in dlopen () from /lib/ld.so.1
> > #7  0x00029290 in load_passwd_gen_dll () at <source code detail
> > deleted>
> > #8  0x0001bbb8 in initialise_server () at <source code detail deleted>
> > #9  0x0001a664 in main (argc=1, argv=0xffbffaec) at <source code
> > detail deleted>
>
> Just from the backtrace I guess nobody will be able to figure
> out what's going on. But let's start with the probably reason-
> able assumption that the internal code of dlopen() etc. is ok.
> But it crashes in there. Then the most probable explanation is
> that you have some memory corruption going on in your program
> that leads to critical data needed by dlopen() getting overwrit-
> ten with junk. That it did seem to work on a different system
> does prove nothing, chances are that you were unlucky enough
> that on the other system the layout in memory was different
> and you just wrote over memory that wasn't relevant, at least
> not for dlopen(), so it didn't crash already there.

Thanks for prompting, I may need to digg more ! However our code
which was running since long for more than 3 different platform
previously...! suddenly start throwing this.

>
>                                Regards, Jens
> --
>   \   Jens Thoms Toerring  ___      j...(a)toerring.de
>    \__________________________      http://toerring.de

From: Rainer Weikusat on
"Raxit(a)mykavita.com" <raxitsheth2000(a)gmail.com> writes:
> any clue for below dump ? same code working on other machine fine.
> Any machine/ OS specific stuff. ?
>
> bash$uname -a
> SunOS <host name> 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-
> Fire-880
>
> (gdb) info threads
> * 1 process 73221 0xff3bf430 in rtld_db_dlactivity () from /lib/
> ld.so.1
>
> (gdb) where
> #0 0xff3bf430 in rtld_db_dlactivity () from /lib/ld.so.1
> #1 0xff3bf5f0 in rd_event () from /lib/ld.so.1
> #2 0xff3b438c in relocate_lmc () from /lib/ld.so.1
> #3 0xff3c5230 in dlmopen_core () from /lib/ld.so.1
> #4 0xff3c52d0 in dlmopen_intn () from /lib/ld.so.1
> #5 0xff3c547c in dlmopen_check () from /lib/ld.so.1
> #6 0xff3c54f0 in dlopen () from /lib/ld.so.1
> #7 0x00029290 in load_passwd_gen_dll () at <source code detail
> deleted>
> #8 0x0001bbb8 in initialise_server () at <source code detail deleted>
> #9 0x0001a664 in main (argc=1, argv=0xffbffaec) at <source code
> detail deleted>

You will need to have a look at the actual faulting instruction. That
should give you a memory address which you can use to start
investigating the root cause of the fault.