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
