[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Core dump

From: Julian Fitzell <julian_at_beta4.com>
Date: 2002-07-26 02:05:58 CEST

Philip Martin wrote:
> Julian Fitzell <julian@beta4.com> writes:
[...]
>
> This indicates stack corruption. You have got to stop before this.
> Try setting a breakpoint on main before running svn. If it stops
> exaimine the stack and see if it looks OK. Then 'step' or 'next' set
> another breakpoint and continue and keep examining the stack until it
> becomes corrupt.

Well, that was useful advice and has generated the weirdest data yet...

[julian@cable static-debug-client-build]$ gdb /usr/local/svnstatic/bin/svn

[...blah blah blah...]

(gdb) break main
Breakpoint 1 at 0x804dfb2: file
../repos/subversion/clients/cmdline/main.c, line 844.
(gdb) s
The program is not being run.
(gdb) r
Starting program: /usr/local/svnstatic/bin/svn

Program received signal SIGSEGV, Segmentation fault.
0x4000acd0 in ?? ()
(gdb) bt
#0 0x4000acd0 in ?? ()
#1 0x40002902 in ?? ()
#2 0x4000f8f6 in ?? ()
#3 0x40002332 in ?? ()
#4 0x4000217f in ?? ()

I'd figure my whole system is hosed except I just compiled apache2 and a
new php and they both worked just fine.

> Try running
>
> $ ldd /usr/local/svnstatic/bin/svn
>
> to see which dynamic libraries are being used, are they the ones you
> expect?

Nothing terribly strange:

[julian@cable static-debug-client-build]$ ldd /usr/local/svnstatic/bin/svn
         libdb-4.0.so => /usr/local/BerkeleyDB.4.0/lib/libdb-4.0.so
(0x4001f000)
         libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400a5000)
         libm.so.6 => /lib/libm.so.6 (0x400ac000)
         libcrypt.so.1 => /lib/libcrypt.so.1 (0x400ce000)
         libnsl.so.1 => /lib/libnsl.so.1 (0x400fc000)
         libdl.so.2 => /lib/libdl.so.2 (0x40113000)
         libz.so.1 => /usr/lib/libz.so.1 (0x40117000)
         libpthread.so.0 => /lib/libpthread.so.0 (0x40125000)
         libc.so.6 => /lib/libc.so.6 (0x4013c000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Obviously there used to be more when it wasn't built static but they
didn't seem wrong then either.

>
>>
>>
>>I attached my config.log just for kicks in case it shows anybody something.
>>
>
>
> [snip]
>
> configure:8357: gcc -o conftest -g -O2 -pthread -DNEON_ZLIB -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -L/usr/local/BerkeleyDB.4.0/lib -L/software/builds/apache2/srclib/apr-util/xml/expat/lib conftest.c >&5
>
> Hmm, what's in /software/builds/apache2/srclib/apr-util/xml/expat/lib?

That's where I built apache2 from... that could have been the problem
except we've now eliminated that by moving my installed apache2 out of
the way so configure can't find apr-config and apu-config.

Thanks for your help.

-- 
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 26 02:07:12 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.