Summary: | gq segfaults with installed with openldap 2.2.14 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Tiggerdine <ptiggerdine> |
Component: | Current packages | Assignee: | Daniel Black (RETIRED) <dragonheart> |
Status: | VERIFIED UPSTREAM | ||
Severity: | normal | CC: | hansmi, leonardop |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://sourceforge.net/tracker/?group_id=3805&atid=103805 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Tiggerdine
2004-08-31 03:05:38 UTC
does gq-1.0-beta2 suffer the same problem? If so compile the program with CFLAGS=-g, FEATURES=nostrip, look for a core file. Then gdb {program} {core} and "where" should show you the code where it failed. Sorry if this isn't that clear - in a rush... Look through http://sourceforge.net/tracker/?group_id=3805&atid=103805 for a fix too. I've recompiled GQ with nostip and "-g" appended tomy gcc line and the ran the core dumped through gdb and got the problem. #0 0x401df970 in ldap_bv2rdn_x () from /usr/lib/libldap-2.2.so.7 Unforunately I'm not a programer so i have no idea what to do with it form here thanks Peter sorry for throwing this hard one on you. To get the stack of function calls enter 'where' on the gdb prompt. This will show hopefully some .c files that contributed towards the seg fault. There are a number of approaches to take here: 1. gq seems to be unmaintained upstream and consider looking for alternatives. I'll consider removing it from the distibution if it just doesn't work. 2. Describe how to quickly set up a testing environment and I'll give it a look when I can. 3. continue debugging with some help from #gentoo-bugs (if your interested in learning a bit) This is the rest of the debug from gdb as asked for (gdb) where #0 0x401df970 in ldap_bv2rdn_x () from /usr/lib/libldap-2.2.so.7 #1 0x401c77c0 in ?? () from /usr/lib/libldap-2.2.so.7 #2 0x40015b78 in _dl_out_of_memory () from /lib/ld-linux.so.2 #3 0x40014860 in _dl_out_of_memory () from /lib/ld-linux.so.2 #4 0xbfffe8e8 in ?? () #5 0x00000110 in ?? () #6 0x08263d08 in ?? () #7 0x401e01c3 in ldap_rdn2bv_x () from /usr/lib/libldap-2.2.so.7 #8 0x00000000 in ?? () #9 0xbfffe8b8 in ?? () #10 0x00000000 in ?? () #11 0x401f96b0 in ?? () from /usr/lib/libldap-2.2.so.7 #12 0x0827f320 in ?? () #13 0x0827f320 in ?? () #14 0x00000000 in ?? () #15 0x401e00a3 in ldap_rdn2str () from /usr/lib/libldap-2.2.so.7 #16 0x08263d08 in ?? () #17 0xbfffe8e8 in ?? () #18 0x00000110 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x4000b2b0 in _dl_rtld_di_serinfo () from /lib/ld-linux.so.2 Previous frame inner to this frame (corrupt stack?) cheers I'm guessing from #2 and #3 you are out of memory. Although the strace doesn't seem to indicate this (brk = 0). Sure the program should handle this gracefully however it doesn't. It looks like the .o files where removed or didn't have permission to read them as a normal user. Try recompiling with # env FEATURES="noclean nostrip" ACCEPT_KEYWORDS=~x86 CFLAGS="-march=athlon-xp -g -pipe" emerge gq # cd /usr/portage/net-nds/openldap # env FEATURES="noclean nostrip" ACCEPT_KEYWORDS=~x86 CFLAGS="-march=athlon-xp -g -pipe" USE="berkdb gdbm" ebuild openldap-2.2.14.ebuild merge (tip - remove -O flags when debugging) # chmod -R ugo+rX /var/tmp/portage/gq-1.0_beta1/ (to set the permissions - this could be what failed) as a normal user: $ gdb /usr/bin/gq (gdb) run when the SEGV occurs (gdb) where (gdb) list On the line where the error occurs try "print" followed by a variable or expression to show the current state of the program e.g. if line 160 failed (gdb) list 158 gtk_main (); 159 160 free_config(config); 161 config = NULL; 162 163 save_state(); 164 165 gtk_exit(0); 166 167 #ifdef DEBUG (gdb) print config $2 = (struct gq_config *) 0x80ce3b8 (gdb) print free_config $3 = {void (struct gq_config *)} 0x8073fc2 <free_config> gq works fine on openldap 2.1.30-r1 for me. Compiling 2.2.14 now for a test. (also noted 2.2.15 is out without an ebuild) Peter can you attach your openldap config file(s) so I can test in the same environment. Any other customised setup appreciated. Also what USE flags did you use with openldap? (emerge -pv openldap) can't debug it without info. Upstream doesn't seem interested in maintaining it either. I've fixed this bug in gq-1.0_beta1-r1. |