Hia free() can segfault if you give it a pointer to unallocated memory(either already free()'d or never malloc()'d ).
The buf array gets always initialized in "_sx_sasl_encode". There is only one function which uses the buffer after this: "gsasl_step", which is a function from the gsasl library - but that shouldn't make the pointer invalid. It's odd that gdb gives you "Failed to read a valid object file image from memory.". Many people say that's it's a kernel bug - maybe you should think about updating if you use an outdated one. A "normal" gdb output of a segfault looks like this: -- Program received signal SIGSEGV, Segmentation fault. 0x0000000000400506 in main () at main.c:7 7 (*p)++; (gdb) bt #0 0x0000000000400506 in main () at main.c:7 -- In my opinion it isn't easy to find out what the problem using emails - the best and easiest thing would be to look at it over ssh with screen in multi-user mode (http://gentoo-wiki.com/HOWTO_Snoop_terminal_session#Screen). I'd really like to have a look at it cause my crystal ball doesn't show anything yet. You can always contact me via jabber ([EMAIL PROTECTED]). ~Shino > Hello, and thank you for responding so quickly, > > I've done that, and it still doesn't give any useful information. > > ========== CONSOLE ========== > # emerge --info | grep FLAGS > CFLAGS="-O2 -march=k8 -pipe -mmmx -msse -msse2 -m3dnow -mfpmath=sse > -ggdb" CXXFLAGS="-O2 -march=k8 -pipe -mmmx -msse -msse2 -m3dnow > -mfpmath=sse -ggdb" # file /usr/bin/router > /usr/bin/router: ELF 64-bit LSB shared object, x86-64, version 1 > (SYSV), for GNU/Linux 2.6.9, not stripped > # gdb /usr/bin/router > GNU gdb 6.7.1 > Copyright (C) 2007 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> This is free software: you are > free to change and redistribute it. There is NO WARRANTY, to the > extent permitted by law. Type "show copying" and "show warranty" for > details. This GDB was configured as "x86_64-pc-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) run -D > Starting program: /usr/bin/router -D > Failed to read a valid object file image from memory. > >>> NAD OP nad_new: 0xa56f210 > .......... > sx (io.c:194) tag 9 event 2 data 0xa584540 > Mon Mar 17 13:21:49 2008 router.c:526 reading from 9 > Mon Mar 17 13:21:49 2008 router.c:584 read 71 bytes > sx (io.c:210) passed 71 read bytes > sx (chain.c:93) calling io read chain > sx (io.c:234) decoded read data (71 bytes): <auth > xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/> > >>> NAD OP nad_new: 0xa5851c0 > >>> NAD OP nad_add_namespace: 0xa5851c0 > >>> NAD OP nad_find_scoped_namespace: 0xa5851c0 > >>> NAD OP nad_add_namespace: 0xa5851c0 > >>> NAD OP nad_find_scoped_namespace: 0xa5851c0 > >>> NAD OP nad_append_elem: 0xa5851c0 > >>> NAD OP nad_append_attr: 0xa5851c0 > >>> NAD OP nad_print: 0xa5851c0 > sx (io.c:89) completed nad: <auth > xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/> > sx (chain.c:119) calling nad read chain > >>> NAD OP nad_find_attr: 0xa5851c0 > sx (sasl_gsasl.c:291) auth request from client (mechanism=DIGEST-MD5) > sx (sasl_gsasl.c:334) sasl context initialised for 9 > > Program received signal SIGSEGV, Segmentation fault. > 0x00002e5b54672715 in ?? () > (gdb) where > #0 0x00002e5b54672715 in ?? () > #1 0x0000000000000001 in ?? () > #2 0x00000d8f0a4385ad in ?? () > #3 0x0000000000000007 in ?? () > #4 0x00000d8f0a5852c0 in ?? () > #5 0x00000071ffffffff in ?? () > #6 0x00000d8f00000000 in ?? () > #7 0x0000000000000000 in ?? () > ========== END ========== > > > Since my original message, I've been trying to run it after adding > some puts() commands throughout the source, and I think the first > problem is here: > ========== CODE (sx/sasl_gsasl.c: 340-400)========== > } else { > puts("NON-ANON"); > /* decode and process */ > _sx_sasl_decode(in, inlen, &buf, &buflen); > puts(buf); > puts("SASL_DECODE"); > } > ret = gsasl_step(sd, buf, buflen, &out, (size_t *) &outlen); > puts("GSASL_STEP"); > if(ret != GSASL_OK && ret != GSASL_NEEDS_MORE) { > puts("NOT NEEDS MORE"); > _sx_debug(ZONE, "gsasl_step failed, no sasl for this conn; (%d): %s", > ret, gsasl_strerror(ret)); > _sx_nad_write(s, _sx_sasl_failure(s, _sasl_err_MALFORMED_REQUEST), 0); > puts("STARTFREE"); > if(out != NULL) free(out); > if(buf != NULL) free(buf); > puts("ENDFREE"); > return; > } > } > > else { > /* decode and process */ > _sx_sasl_decode(in, inlen, &buf, &buflen); > if(!sd) { > _sx_debug(ZONE, "response send before auth request enabling mechanism > (decoded: %.*s)", buflen, buf); > _sx_nad_write(s, _sx_sasl_failure(s, _sasl_err_MECH_TOO_WEAK), 0); > if(buf != NULL) free(buf); > return; > } > _sx_debug(ZONE, "response from client (decoded: %.*s)", buflen, buf); > ret = gsasl_step(sd, buf, buflen, &out, (size_t *) &outlen); > } > > puts("0:FREE BUF"); > if(buf != NULL) free(buf); > puts("0:FREED BUFF"); > ========== CONSOLE ========== > sx (io.c:234) decoded read data (71 bytes): > sx (io.c:89) completed nad: > sx (chain.c:119) calling nad read chain > sx (sasl_gsasl.c:291) auth request from client (mechanism=DIGEST-MD5) > sx (sasl_gsasl.c:334) sasl context initialised for 6 > SASL CONTEXT INIT > VOID SD > NON-ANON > > SASL_DECODE > GSASL_STEP > 0:FREE BUF > > Program received signal SIGSEGV, Segmentation fault. > 0x000031b7b4783715 in ?? () > ========== END ========== > Why would a free() cause a segfault? > > - Neil > > > > On Mon, Mar 17, 2008 at 11:16 AM, Joël Bohnes > <[EMAIL PROTECTED]> wrote: > > On Mon, 17 Mar 2008 10:16:51 -0700 > > "Kenji Miyamoto" <[EMAIL PROTECTED]> wrote: > > > > Hi Neil > > > > I'm sorry but the gdb backtrace is not really holpefull because the > > binary doesn't contain any debug information. You have to tell gcc > > that you want to include debug information in the binary - if you > > do so you'll have specific information at which point the program > > segfaults. > > > > Gentoo has a really nice guide to show how to make good backtraces: > > http://www.gentoo.org/proj/en/qa/backtraces.xml > > > > To make it short, please do the following things to get a good > > backtrace: > > *Edit your make.conf and add '-ggdb' to your CFLAGS. > > > > *Recompile jabberd the following way: 'FEATURES=nostrip emerge > > jabberd2' > > > > *Remove the '-ggdb' from your CFLAGS because you don't want your > > other applications to be built with debug information. > > > > If you did so, please send a new backtrace using gdb. > > > > ~Shino > > > > > > > > > Hello everyone, > > > > > > After running just fine for months, Jabberd2's router somehow > > > started to crash within the sasl_gsasl.c file. I ran the router > > > under gdb with debug output turned on (-D). I'm not quite sure > > > what else I can provide, other than this is Gentoo's Jabberd2 > > > version 2.1.21 using PostgreSQL 8.2.6, and fails regardless of > > > my chosen CFLAGS. What could be the cause of the segfaults? > > > > > > - Neil > > > > > > ========== OUTPUT ========== > > > > > > sx (io.c:234) decoded read data (71 bytes): <auth > > > xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/> > > > >>> NAD OP nad_new: 0xc832be10 > > > >>> NAD OP nad_add_namespace: 0xc832be10 > > > >>> NAD OP nad_find_scoped_namespace: 0xc832be10 > > > >>> NAD OP nad_add_namespace: 0xc832be10 > > > >>> NAD OP nad_find_scoped_namespace: 0xc832be10 > > > >>> NAD OP nad_append_elem: 0xc832be10 > > > >>> NAD OP nad_append_attr: 0xc832be10 > > > >>> NAD OP nad_print: 0xc832be10 > > > sx (io.c:89) completed nad: <auth > > > xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/> > > > sx (chain.c:119) calling nad read chain > > > >>> NAD OP nad_find_attr: 0xc832be10 > > > sx (sasl_gsasl.c:291) auth request from client > > > (mechanism=DIGEST-MD5) sx (sasl_gsasl.c:334) sasl context > > > initialised for 9 > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0x00002d46e72f1715 in ?? () > > > (gdb) where > > > #0 0x00002d46e72f1715 in ?? () > > > #1 0x0000000000000001 in ?? () > > > #2 0x000004f5c81db5ad in ?? () > > > #3 0x0000000000000008 in ?? () > > > #4 0x000004f5c832bf10 in ?? () > > > #5 0x00000071ffffffff in ?? () > > > #6 0x000004f500000000 in ?? () > > > #7 0x0000000000000000 in ?? () > > > > > >
signature.asc
Description: PGP signature
