|
From: Tom H. <to...@co...> - 2005-11-12 17:41:05
|
In message <2a2...@ma...>
Paul Pluzhnikov <ppl...@gm...> wrote:
> ==29870== Process terminating with default action of signal 11 (SIGSEGV)
> ==29870== at 0x4EACC1EC: dl_main (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EADA3F7: _dl_sysdep_start (in /lib/ld-2.3.2.so<http://2.3.2.so>
> )
> ==29870== by 0x4EACC082: _dl_start (in /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870== by 0x4EACBC46: (within /lib/ld-2.3.2.so <http://2.3.2.so>)
> ==29870==
>
>
> Is that using glibc-2.3.2-95.20.i686.rpm or a later update?
>
>
> $ rpm -qf /lib/ld-2.3.2.so <http://2.3.2.so>
> glibc-2.3.2-95.20
>
> Also, I tried to see if I can debug core. Default "ulimit -c" is zero;
> setting it to unlimited changes the message:
> ==29946== Process terminating with default action of signal 11 (SIGSEGV):
> dumping core
>
> but no core* is produced :(
That is a core dump of the client program so will be a vgcore* file.
> Attaching to program: /proc/30077/fd/1014, process 30077
> 0x4eacc1ec in ?? ()
> (gdb) x/i $pc
> 0x4eacc1ec: mov %ecx,(%esp)
> (gdb) x/x $esp
> 0xfef12ec0: Cannot access memory at address 0xfef12ec0
> (gdb) shell cat /proc/30077/maps
> 0000000004000000-000000000435a000 rwxp 0000000000000000 00:00 0
> 000000000435a000-000000000435c000 ---p 000000000035a000 00:00 0
> 000000000435c000-000000000436c000 rwxp 000000000035c000 00:00 0
> 000000000436c000-000000000436e000 ---p 000000000036c000 00:00 0
> 000000000436e000-000000000437e000 rwxp 0000000000000000 00:00 0
> 0000000004577000-0000000005f69000 rwxp 0000000000000000 00:00 0
> 0000000008048000-0000000008049000 r-xp 0000000000000000 03:41 200779
> /tmp/a.out
> 0000000008049000-000000000804a000 rwxp 0000000000000000 03:41 200779
> /tmp/a.out
> 000000000804a000-000000000804b000 rwxp 0000000000000000 00:00 0
> 000000004eacb000-000000004eae0000 r-xp 0000000000000000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 000000004eae0000-000000004eae1000 rwxp 0000000000014000 03:41 510225
> /lib/ld-2.3.2.so <http://2.3.2.so>
> 0000000070000000-0000000070135000 r-xp 0000000000000000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070135000-0000000070136000 rwxp 0000000000135000 03:41 772191
> /usr/local/valgrind-3.0.svn/lib/valgrind/x86-linux/memcheck
> 0000000070136000-00000000707c2000 rwxp 0000000000000000 00:00 0
> 00000000fef13000-00000000fef14000 rwxp 0000000000000000 00:00 0
> 00000000fff13000-00000000ffffe000 rw-p fffffffffff16000 00:00 0
> (gdb) quit
> ==30076==
> ==30076== Debugger has detached. Valgrind regains control. We continue.
> ==30076==
> ==30076== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> ==30076== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==30076== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==30076== For counts of detected errors, rerun with: -v
> ==30076== No malloc'd blocks -- no leaks are possible.
> Segmentation fault
>
> Hmm; %esp is just below the stack page, and the kernel refuses to grow
> stack?
That's the original kernel supplied stack though isn't it? and we
shouldn't be giving that to the client program - we allocate a new
stack for that.
> In fact, increasing environment size moves the place where it coredumps,
> and invreasing it sufficiently makes it run:
Interesting. I'll have a play with that. Any idea roughly what
sizes of environment cause a problem?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|