Alright, got the backtrace. One concern... there is a really long string on escaped octal(?) numbers... Is that the key itself? It's fine if it is, I can generate new keys, just want to check.
(gdb) r -d Starting program: /home/adswadmin/stuff/nss-pam-ldapd-0.7.13/nslcd/nslcd -d [Thread debugging using libthread_db enabled] nslcd: DEBUG: add_uri(ldap://ldap1.bcrs-vaults.ibm.com) Program received signal SIGSEGV, Segmentation fault. __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:129 129 ../sysdeps/x86_64/multiarch/strcmp.S: No such file or directory. in ../sysdeps/x86_64/multiarch/strcmp.S Current language: auto The current source language is "auto; currently asm". (gdb) bt #0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:129 #1 0x00000000004088e7 in get_restdup (filename=<value optimized out>, lnr=<value optimized out>, keyword=0x7fffffffe4e0 "tls_ciphers", line=0x1c, var=0x7fffffffe518) at cfg.c:418 #2 0x0000000000409e19 in cfg_read (filename=0x416ca6 "/etc/nslcd.conf", cfg=0x61e650) at cfg.c:979 #3 0x000000000040a529 in cfg_init (fname=0x416ca6 "/etc/nslcd.conf") at cfg.c:1160 #4 0x000000000040378b in main (argc=-178911408, argv=<value optimized out>) at nslcd.c:631 (gdb) bt -full No symbol "full" in current context. (gdb) bt full #0 __strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp.S:129 No locals. #1 0x00000000004088e7 in get_restdup (filename=<value optimized out>, lnr=<value optimized out>, keyword=0x7fffffffe4e0 "tls_ciphers", line=0x1c, var=0x7fffffffe518) at cfg.c:418 No locals. #2 0x0000000000409e19 in cfg_read (filename=0x416ca6 "/etc/nslcd.conf", cfg=0x61e650) at cfg.c:979 fp = 0x61ea30 lnr = 27 linebuf = "tls_ciphers TLSv1\000\000in,dc=example,dc=com\000\000by root.\000\000.\000\000eachable.\000\000\325\377\377\377\177\000\000\000 \000@\250\377\377\377\377\000\000\226\213\275\357\377\377", '\000' <repeats 32 times>"\220, \344\377\377\377\177\000\000\000\345\377\377\377\177\000 \000\320t\376\367\377\177\000\000\003\000\000\000\000\000\000\000Ȇm\366\377 \177\000\000@\326\377\377\377\177\000\000\022\274\336\367\377\177\000\000 \000\000\000\000\000\000\000\000\346\305\336\367\377\177\000\000\270\337 \377\367\377\177\000\000\270\344\377\377\377\177\000\000\300\344\377\377 \377\177\000\000\317\344\377\377\377\177\000\000\340\273\336\367\377\177 \000\000\300hm\366\377\177\000\000\000\345\377\377\377\177\000\000b\256\336 \367\377\177\000\000\200\231\376\367\377\177", '\000' <repeats 13 times>"\312, \377\377\377\377\320t\376\367\377\177\000\000\003\000\000\000 \000\000\000\000Ȇm\366\377\177\000\000@\326\377\377\377\177\000\000\000\000 \252\377\377\377\377\000\000\226\213\275\357\377\377", '\000' <repeats 64 times>"\220"... line = 0x7fffffffd45c "TLSv1" keyword = "tls_ciphers\000\377\177\000\000\000\004\000\000\000\000 \000\000\246lA\000>\000\000" token = "start_tls\000p1.bcrs-vaults.ibm.com\000\256S\367\377\177 \000\000\250\256S\367\377\177\000\000\001\000\000\000\377\177\000\000\320 \003\000\000\000\000\000" ---Type <return> to continue, or q <return> to quit--- i = 17 rc = <value optimized out> value = 0x3d0 <Address 0x3d0 out of bounds> #3 0x000000000040a529 in cfg_init (fname=0x416ca6 "/etc/nslcd.conf") at cfg.c:1160 i = <value optimized out> #4 0x000000000040378b in main (argc=-178911408, argv=<value optimized out>) at nslcd.c:631 i = <value optimized out> (gdb) -- Isaac Freeman - Systems Administrator IBM Information Protection Services is...@us.ibm.com 919-254-0245 From: Arthur de Jong <adej...@debian.org> To: Isaac Freeman/Raleigh/Contr/IBM@IBMUS, 638...@bugs.debian.org Date: 08/23/2011 03:55 PM Subject: Re: Bug#638872: nslcd: segfault when tls_ciphers is declared On Mon, 2011-08-22 at 17:24 -0400, Isaac Freeman wrote: > As for the gdb, I'm not sure how to get the dbg symbols for nslcd, > there is no nslcd-dbg package. When print the bt I just get hex > addresses. Do you want those anyways? Not sure if they'll do you any > good... Or I can attach a core dump to the bug or upload it somewhere. A backtrace, even with just hex data would be more useful than a coredump because I think I need an amd64 machine to load the coredump in gdb. You could try to make a backtrace by compiling nslcd from source (http://arthurdejong.org/nss-pam-ldapd/). You need the following packages to build it: libkrb5-dev libldap2-dev libsasl2-dev libpam0g-dev (just ./configure;make should be enough) Thanks (the config you provided should be OK and I can't reproduce it with that config). -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- [attachment "signature.asc" deleted by Isaac Freeman/Raleigh/Contr/IBM]
<<inline: graycol.gif>>
