Hia, Really try once to compile jabberd with PIE disabled. I've found a segfault which occurs when I build it with PIE.
~Shino On Tue, 18 Mar 2008 20:22:45 -0700 "Kenji Miyamoto" <[EMAIL PROTECTED]> wrote: > Hello again, > > Yeah, it works just fine on my desktop, and even if I tell my server's > Jabberd2 to use SQLite, it still fails. What's strange is that it > worked for months, then when a friend of mine tried to log in > everything broke. He didn't even do anything strange, or register. > > Do you have any ideas on this? I'm lost. > > - Neil > > On Tue, Mar 18, 2008 at 7:44 PM, Kenji Miyamoto > <[EMAIL PROTECTED]> wrote: > > Hello, > > > > I forgot to mention that I'm using a self-signed SSL certificate > > and PostgreSQL as the backend. I doubt that matters, but the > > details are important sometimes. > > > > - Neil > > > > > > > > On Tue, Mar 18, 2008 at 6:15 AM, Joël Bohnes > > <[EMAIL PROTECTED]> wrote: > > > Hia > > > > > > If the hardened toolchain makes gdb unable to use then you can > > > just change the toolchain before compiling jabberd2. Use > > > 'gcc-config -l' to look up the number that belongs to the > > > vanilla toolchain and use 'gcc-config $number' to switch to that > > > toolchain. > > > > > > Note that paludis uses /etc/paludis/bashrc instead > > > of /etc/make.conf. Just in case you used paludis to install > > > jabberd2. > > > > > > I don't know why the ebuild manager of jabberd2 forces the use > > > of libidn-0.6* - we use jabberd2 with libidn-1.0-r1 without any > > > problems. libidn-0.6.9-r2 installs fine here - the AC_PROG_JAVAC > > > macro is defined in libidn-0.6.9/m4/ac_prog_javac.m4 and I don't > > > see any reason why autoconf shouldn't find it. But I'm not so > > > familiar with the GNU autotools. > > > > > > --autoconf.c-- > > > if test "$enable_java" != "no"; then > > > AC_PROG_JAVAC > > > AC_PROG_JAR > > > AM_MISSING_PROG(GJDOC, gjdoc, $missing_dir) > > > fi > > > -- > > > So it appears to be only used when java is enabled - you could > > > try to disable java unless you really need it. > > > > > > ~Shino > > > > > > > > > > > > > > > > Hello again, > > > > > > > > I forgot to mention that this system is on a kernel with PaX > > > > and Grsecurity, so GDB doesn't work too well on it. > > > > > > > > I would install Jabberd2 on a more normal machine, except > > > > this problem surfaces when installing the old version of > > > > libidn Jabberd2 needs. > > > > > > > > - Neil > > > > > > > > # > > > > cat /var/tmp/paludis/net-dns/libidn-0.6.9-r2/temp//autoconf-29295.out > > > > ***** autoconf ***** > > > > > > > > configure.ac:107: error: possibly undefined macro: > > > > AC_PROG_JAVAC If this token and others are legitimate, please > > > > use m4_pattern_allow. See the Autoconf documentation. > > > > configure.ac:108: error: possibly undefined macro: AC_PROG_JAR > > > > > > > > > > > > > > > > > > > > On Mon, Mar 17, 2008 at 4:04 PM, Joël Bohnes > > > > <[EMAIL PROTECTED]> wrote: > > > > > 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
