Re: [Sks-devel] recon segfaulting

[Yaron Minsky]

Can you try with:
  a) a fresh database, and
  b) a build done directly from the sks-1.0.7 tarball?

I want to eliminate the possibility that this bug comes from changes
introduced in the debian packaging process.  I am running 1.0.7 on my
system with no problems, and I didn't make any changes recently that hit
the segfaultable part of the code (the interface to Berkeley DB).  It's
possible that an old bug is being exercised, but it could also be some
weird build bug.

Also, I would recommend not using the basedir option for now.  I haven't
looked at it lately, but there have been reports of bugginess there.  That
being said, it's hard to see how that would cause a segfault.

y

Jan Dreyer said:
> Hi,
>
> Peter Palfrader wrote:
>
>> The recon process segfaulted twice on me since I upgraded to a later cvs
>> version (I'm running
>> https://svn.clearairturbulence.org/debian-sks/trunk/sks/)
>>
>> Unfortunately I can't tell you what is causing this.  I'll try to build
>> without stripping and running it with coredumps enabled.
>>
>> [2]  + segmentation fault  /usr/sbin/sks -basedir . recon
>
> same is here :-(
> My database seems ok now and all mailsyncs are imported correctly. So far
> so good ...
>
> Just got the 1.0.7 from your svn, but its the same.
> GDB put these lines out:
> ---
> This GDB was configured as "i386-linux"...
> (gdb) run recon
> Starting program: /usr/sbin/sks recon
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x4018ebb8 in free () from /lib/libc.so.6
> ---
> strace's last lines are these:
>
> --- snipp ---
> pread(7, "\10\0\0\0l\213\24\0\263\7\2\0\0\0\0\0\264\7\2\0\1\0\346"...,
> 512,
> 68118016) = 512
> pread(7, "\10\0\0\0l\213\24\0\264\7\2\0\263\7\2\0\0\0\0\0\1\0\25"..., 512,
> 68118528) = 512
> --- SIGSEGV (Segmentation fault) ---
> rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0
> sigreturn()                             = ? (mask now [])
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
> --- snapp ---
>
> this is what i get with debug-level 7:
> ---
> 2004-03-15 17:07:01 Opening log
> 2004-03-15 17:07:01 sks_recon, SKS version 1.0.7
> 2004-03-15 17:07:01 Copyright Yaron Minsky 2002-2003
> 2004-03-15 17:07:01 Licensed under GPL.  See COPYING file for details
> 2004-03-15 17:07:01 recon port: 23011
> 2004-03-15 17:07:01 Opening PTree database
> 2004-03-15 17:07:01 Setting up PTree data structure
> 2004-03-15 17:07:01 PTree setup complete
> 2004-03-15 17:07:01 Initiating catchup
> 2004-03-15 17:07:01 Marshalling: LogQuery: (5000,1079324493.475435)
> 2004-03-15 17:07:01 Unmarshalling: LogResp: 5000 events
> ---
>
> model name      : Intel(R) Pentium(R) 4 CPU 1500MHz
>          total:    used:    free:  shared: buffers:  cached:
> Mem:  263036928 247685120 15351808        0     8192 192479232
> Swap: 254971904  7942144 247029760
>
> Btw: the sks_recon dies directly after calculating DB stats when starting
> with -initial_stat
>
> Maybe someone got a clue from these debugging-informations?
>
> Greetings
> Jan Dreyer
> --
> ZIT (Zentrum IT-Dienste)                               +-----------+
>                                      |     USE PGP!     |\  O---m  /|
> Let the SUN shine in your heart ;-) | (key via server  |/`-------'\|
> -> zustaendig fuer: Unix-Server, CA |  or on request)  +-----------+
>


|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916