[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] Segfault in v1.0.4
From: |
Daniel Johnson |
Subject: |
Re: [Sks-devel] Segfault in v1.0.4 |
Date: |
Sat, 01 Nov 2003 22:40:22 -0600 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Discovery is using a hair over 26mb right now.
I've had sks_db, sks_recon, build, pbuild, and (I think)
clean_keydb give segfaults so far. Earlier, I could run build
and sks_db one (1) time without trouble. If I shutdown and
restart sks_db it would blow up. pbuild never would work.
After that, my only choice was to delete the database
directories and try again.
address@hidden:~$ sks_db -debuglevel 10
2003-11-01 22:14:19 Membership: <ADDR_INET
68.91.150.38:11370>(dannyj.dynip.com 11370)
Segmentation fault
I also tried that with no 'membership' file. It just leaves off
the first line.
address@hidden:~$ sks_recon -debuglevel 10
Segmentation fault
I killed and rebuilt the database, which got it working one more
time. Added a key via the web interface. Shut it down, tried
to restart. Segfault. Tried to delete/rebuild again. Didn't
work this time.
I'm reminded that ocaml did not compile properly the first time.
Following their instructions, I re-ran the compile and it
worked. Do you think a total recompile would help?
Or maybe I'm overlooking the obvious: This system is old, and in
dire need of a complete rebuild. Perhaps some of the libraries
are a bit quirky after all this time. At least the kernel is
recent (2.4.21).
Yaron: If it would help, I can arrange for you to have access to
that account.
On 1 Nov 2003 at 21:47, Yaron M. Minsky wrote:
> Hmm. This is quite strange. The sks_db and sks_recon
processes do NOT
> need huge amounts of memory --- on the order of 10-30 each.
Right now
> they're together taking 25 megs on my machine.
>
> Are you talking about sks_db and sks_recon or
build/fastbuild/pbuild?
> If so, exactly which one fails, and why? keyserver.bu.edu is
a 128 meg
> machine, and SKS works just dandy on it.
>
> So, I guess the next step is to provide some more detailed
info about
> exactly which executable fails and where. By the way, the way
to get
> more debugging info is not to set the debug flag (which is set
by
> default anyway) but to set the debuglevel to something high.
The
> default is 3, 5-6 is pretty verbose, and 10 will give you a
printout of
> every message passed through the system.
>
> y
- --
Through the modem, off the server, over the T1, past the
frame-relay,
< < NOTHIN' BUT NET > >
Daniel Johnson
address@hidden
http://dannyj.come.to/
Public PGP Keys & other info: http://dannyj.come.to/pgp/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (MingW32) - GPGshell v2.95
iD8DBQE/pIqT6vGcUBY+ge8RAiDzAJ9sukKMm9o7yhM9WQYl6d4xmRYbtACgx1Ll
CO/NhorqkGRlCop5rXQa2r4=
=1xTX
-----END PGP SIGNATURE-----