[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Autorouter segfaults
On Sun, Mar 12, 2006 at 09:55:59PM +0100, kmk wrote:
> Karel Kulhavy wrote:
>
> > Do:
> > ulimit -c unlimited
> > rm core*
> > reproduce the error
>
> ok, did that.
>
>
> > gdb `which pcb-bin` core*
>
> I get:
>
> GNU gdb 6.3-debian
> <snip>
> This GDB was configured as "i386-linux"...(no debugging symbols
> found)
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
>
> (no debugging symbols found)
> Core was generated by `/usr/bin/pcb-bin
> PCB_ModulPID_segfault.pcb'.
> Program terminated with signal 11, Segmentation fault.
>
> warning: current_sos: Can't read pathname for load map:
> Input/output error
>
> Reading symbols from /lib/tls/libm.so.6...(no debugging symbols
> found)...done.
> Loaded symbols for /lib/tls/libm.so.6
> Reading symbols from /usr/lib/libgtk-x11-2.0.so.0...(no
> debugging symbols found)...done.
> Loaded symbols for /usr/lib/libgtk-x11-2.0.so.0
> Reading symbols from /usr/lib/libgdk-x11-2.0.so.0...
> (no debugging symbols found)...done.
> [...]
> Seems like all my libs are stripped :-|
>
> > bt full
>
> #0 0x080bab40 in ?? ()
> No symbol table info available.
> #1 0xbfffe4a0 in ?? ()
> No symbol table info available.
> #2 0x084d5320 in ?? ()
> No symbol table info available.
> #3 0xbfffe428 in ?? ()
> No symbol table info available.
> #4 0x080bab84 in ?? ()
> No symbol table info available.
> #5 0x082e18f8 in ?? ()
> No symbol table info available.
> #6 0xffffffff in ?? ()
> No symbol table info available.
> #7 0xbfffe448 in ?? ()
> No symbol table info available.
> #8 0x404faba3 in g_malloc0 () from /usr/lib/libglib-2.0.so.0
> No symbol table info available.
> Previous frame inner to this frame (corrupt stack?)
> (gdb)
>
>
> I also did an strace (result attached to this mail)
Strace monitors only I/O, not memory access and function calls. Not
likely to reveal the cause of a segfault.
Try to recompiling the PCB with the -g option. I don't know how this is
done. I don't expect this to be described in the user doc. I first try
export CFLAGS=-g and monitoring if make calls the gcc with -g. Sometimes
it works, sometimes it fails. Then I reverse engineer the makefile. Also
check if the makefile contains a call to strip and if, then
delete it.
Then you may get a meaningful stack trace. Or maybe not, if PCB
overwrote the stack with garbage.
Looks like it blew in in g_malloc. I don't expect g_malloc to blow up
unless the memory allocation records are corrupted. Stack trace doesn't
reveal memory corruption anyway. Try also linking with electric fence
(are the developers trying it with efence at all). That should give
a zap when the program starts shooting around and produce more
meaningful stack trace that points the developer's nose to the place
where he's doing a double-free, buffer overflow or other cool halfpipe
trick.
CL<
>
>
> ---<(kaimartin)>---
> --
> Kai-Martin Knaak
> kmk@xxxxxxxxxxxxxxx
> Blog: http://lilalaser.dyndns.org/blog