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 ?? () > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- To unsubscribe send a mail to [EMAIL PROTECTED]
