[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgp-keyserver-folk
Subject:    [Pgp-keyserver-folk] duplicates..
From:       Ethan Weinstein <lists () stinkfoot ! org>
Date:       2003-01-31 5:43:40
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Recently I rebuilt stinkfoot's db using recent cvs code to test David's patches,
and I've been getting segfaults from both pksclient (manual add) and pksd
(addition through email, web, or gnupg) when certain duplicate keyids are added.
~ Oddly, other dupes seem to get comitted without incident.
I'm wondering if something slipped into cvs that's causing this?  David said he
attempted this on an ix86 machine and didn't get segfaults from adding the dupes.
This is driving me nuts, as those keys are showing up in all
the keydumps I've been going through, and each time I hit one..
segfault.  Now perhaps I'm odd-man-out because I use a PowerPC, but I know that
these keys made it into my db using old pksd-0.9.4 with patch2 applied without
crashes.  Any ideas?  I'm up to testing just about anything at this point =)

Here's a stack trace from one of the crashes, this one from keyid 0xDE0E525D

[Mon Jan 27 12:49:18 2003] display_new_key: new keyid 197663 DE0E525D
[Mon Jan 27 12:49:18 2003] display_new_key: new keyid 197664 DE0E525D

Program received signal SIGSEGV, Segmentation fault.
__libc_free (mem=0xde0e525d) at malloc.c:3135
3135    malloc.c: No such file or directory.
~        in malloc.c
(gdb) bt
#0  __libc_free (mem=0xde0e525d) at malloc.c:3135
#1  0x1000e0fc in xbuffer_free (xb=0x10071888) at util.c:36
#2  0x10009ea0 in userids_elem_free (e=0x10071888, c=0x0) at kd_types.c:64
#3  0x1000db9c in llist_iterate_1 (elems=0x100754e8, nelems=268896736,
i=0x10009e7c <userids_elem_free>, c=0x0)
~    at llist.c:133
#4  0x1000dc18 in llist_iterate (l=0xde0e525d, i=0, c=0x0) at llist.c:143
#5  0x10009f6c in keys_elem_free (e=0x100709e0, c=0x0) at kd_types.c:85
#6  0x1000db9c in llist_iterate_1 (elems=0x10076fc8, nelems=2,
i=0x10009eec <keys_elem_free>, c=0x0) at llist.c:133
#7  0x1000dc18 in llist_iterate (l=0xde0e525d, i=0, c=0x0) at llist.c:143
#8  0x10003704 in db_key_merge_1 (e=0x100709e0, c=0x0) at kd_add.c:1175
#9  0x10003778 in db_key_merge (e=0x100709e0, c=0x0) at kd_add.c:1188
#10 0x10007614 in finish_pubkey (s=0x7fffec38) at kd_search.c:223
#11 0x100076d4 in make_keys_elem (packet=0x7fffeba8, c=0x0) at
kd_search.c:254
#12 0x1000ac94 in decode_packet (data=0x7fffec28, h=0x10007644
<make_keys_elem>, c=0x7fffec38) at pgputil.c:500
#13 0x1000ad04 in decode_binary (data=0x7fffec28, h=0x10007644
<make_keys_elem>, c=0x7fffec38) at pgputil.c:509
#14 0x1000adac in decode_file (data=0x7fffec28, h=0x10007644
<make_keys_elem>, c=0x7fffec38) at pgputil.c:525
#15 0x10007e30 in kd_keyblock_iterate (block=0xde0e525d <Address
0xde0e525d out of bounds>, blocklen=0,
~    iter=0x10009e7c <userids_elem_free>, c=0x0, err=0x51,
softerr=0xffdec68) at kd_search.c:592
#16 0x10003894 in kd_add_1 (keys=0x30027000 "\231\001¢\0048(jL\021\004",
len=858648037, flags=3145728, win_msg=0x7ffff968,
~    newkeys_xb=0x7ffff978, err=0x7ffff558) at kd_add.c:1238
#17 0x10004018 in kd_add (keys=0x30027000 "\231\001¢\0048(jL\021\004",
len=858648037, flags=3145728, ret=0x7ffff9dc,
~    retlen=0x7ffff9e8, newkeys=0x7ffff9e0, newkeyslen=0x7ffff9e4) at
kd_add.c:1475
#18 0x10001534 in main (argc=-569486755, argv=0x7ffffa74) at pksclient.c:109
#19 0x0fecd010 in __libc_start_main (argc=5, ubp_av=0x7ffffa74,
ubp_ev=0x10009e7c, auxvec=0x7ffffae0,
~    rtld_fini=0xde0e525d, stinfo=0x100493c0, stack_on_entry=0x14) at
../sysdeps/powerpc/elf/libc-start.c:119
(gdb)


- -E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+Og0LYG9JFqgeXDURAqrvAKCh8hkXP+R2Ay52Ua8vc/ucnJ3fYgCgm7R3
5NdGdinpL+M3Bya8ghJrAKc=
=1N7t
-----END PGP SIGNATURE-----

[prev in list] [next in list] [prev in thread] [next in thread]