Re: off-topic traceback weirdness

[Robert Schweikert <rjschwei at cox dot net>]

On Sat, 2003-05-10 at 03:48, Andreas Jaeger wrote:
> Robert Schweikert <rjschwei@cox.net> writes:
> 
> > rjschwei@triumph /noSymsTrace-> g++ -c -fpic -I. oneA.C
> > rjschwei@triumph /noSymsTrace-> g++ -L. -shared -fpic -o libOneA.so
> > oneA.o
> > rjschwei@triumph /noSymsTrace-> g++ -I. -L. -o stkLibsTOneSO oneSOMain.C
> > -lOneA
> > rjschwei@triumph /noSymsTrace-> ./stkLibsTOneSO
> > This is main
> > This is A
> > Segmentation fault (core dumped)
> > rjschwei@triumph /noSymsTrace-> gdb stkLibsTOneSO core
> > GNU gdb 5.3
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "i586-suse-linux"...
> > Core was generated by `./stkLibsTOneSO'.
> > Program terminated with signal 11, Segmentation fault.
> > #0  0x40015928 in ?? ()
> > (gdb) where
> > #0  0x40015928 in ?? ()
> > #1  0x400158e1 in ?? ()
> > #2  0x08048627 in main ()
> > #3  0x401238ae in ?? ()
> 
> And this part I cannot reproduce - I just tried on two different
> systems both running SuSE Linux 8.2.  The only difference is that I
> used bash and therefore did additionally:
> $ ulimit -c unlimited
> $ export LD_LIBRARY_PATH=`pwd`
> 

I use tcsh and have "limit coredumpsize unlimited" in my .cshrc file

-> limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       unlimited
coredumpsize    unlimited
memoryuse       unlimited
vmemoryuse      unlimited
descriptors     1024
memorylocked    unlimited
maxproc         7168

I have the problem on 2 systems.

> 
> $ gdb stkLibsTOneSO core
> GNU gdb 5.3
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i586-suse-linux"...
> Core was generated by `./stkLibsTOneSO'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /tmp/libOneA.so...done.
> Loaded symbols for /tmp/libOneA.so
> Reading symbols from /usr/lib/libstdc++.so.5...done.
> Loaded symbols for /usr/lib/libstdc++.so.5
> Reading symbols from /lib/libm.so.6...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libgcc_s.so.1...done.
> Loaded symbols for /lib/libgcc_s.so.1
> Reading symbols from /lib/libc.so.6...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  0x40015928 in foo::getNumber() () from /tmp/libOneA.so
> (gdb) bt
> #0  0x40015928 in foo::getNumber() () from /tmp/libOneA.so
> #1  0x400158e1 in A::getNumber() () from /tmp/libOneA.so
> #2  0x08048627 in main ()
> #3  0x401248ae in __libc_start_main () from /lib/libc.so.6
> 
> >
> >
> > I do not expect line numbers here, only function names. The executable
> > is not stripped.
> >
> > rjschwei@triumph /noSymsTrace-> file stkLibsTOneSO
> > stkLibsTOneSO: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
> > dynamically linked (uses shared libs), not stripped
> 
> $ file stkLibsTOneSO 
> stkLibsTOneSO: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
> 
> So, something must be different between our environments.  Do you have
> enough space to write the core file?  Mine use 180224 bytes.

There's pleant of disk space

-> pwd
/a/rjschwei/work/noSymsTrace
rjschwei@triumph /noSymsTrace-> df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             34077096  15108912  18968184  45% /


My core file is always "too small" 

-> ls -l core
-rw-------    1 rjschwei users       61440 May 10 06:16 core

Thanks,
Robert

> 
> Andreas
-- 
Robert Schweikert <rjschwei@cox.net>