|
From: Raxit on 4 Jul 2008 08:30 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 4 Jul 2008 09:11 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 4 Jul 2008 10:56 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 6 Jul 2008 03:55 "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.
|
Pages: 1 Prev: Question about struct in shared memory (C on linux) Next: Solaris 5.10 cpu hike --- _flockget |