Date: Fri, 08 Dec 2006 15:47:44 -0500 From: Joe Marcus Clarke <marcus@marcuscom.com> To: Micah <micahjon@ywave.com> Cc: gnome@freebsd.org, bug-followup@freebsd.org Subject: Re: ports/105589: Firefox 2.0 segfaults when saving more than one file per session Message-ID: <4579CF70.3070703@marcuscom.com> In-Reply-To: <4579C1E0.6000703@ywave.com> References: <200612061930.kB6JUJVA038980@freefall.freebsd.org> <1165476509.74826.14.camel@shumai.marcuscom.com> <4578AB25.2020504@ywave.com> <1165565003.15396.7.camel@shumai.marcuscom.com> <4579C00E.2040905@ywave.com> <4579C125.3040106@marcuscom.com> <4579C1E0.6000703@ywave.com>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Micah wrote: > Joe Marcus Clarke wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Micah wrote: >>> Joe Marcus Clarke wrote: >>>> On Thu, 2006-12-07 at 16:00 -0800, Micah wrote: >>>>> Joe Marcus Clarke wrote: >>>>>> Before anything can be done to fix this, someone needs to provide a >>>>>> backtrace with full debugging symbols. For more on doing this, see >>>>>> http://www.freebsd.org/gnome/docs/bugging.html . >>>>>> >>>>>> Joe >>>>> Anything else I can provide? >>>> This backtrace appears corrupt. I do not see how it dies in endian.h. >>>> Rebuild libc and libpthread with debugging symbols, and get a new >>>> trace. >>>> >>>> Joe >>>> >>> Okay, but it still died in endian.h. I then rebuilt world with debugging >>> symbols in hope that there's some other library somewhere that needed >>> them, but the stack trace still ends in endian.h >>> >>> I followed it through the debugger in hopes of getting you something >>> more useful. It segfaults while executing line 357 of xdgmimecache.c, >>> (which is: XdgMimeCache *cache = _caches[i]; inside >>> cache_glob_lookup_literal). Stepping into that line of code sends the >>> debugger to endian.h. Is there another non-system library that I need to >>> add debugging symbols to? >> >> What endian.h files do you have on your system? What does: >> >> (gdb) frame 0 >> (gdb) l >> >> Report? >> >> Joe > > (gdb) frame 0 > #0 0x48614d0e in cache_glob_lookup_literal ( > file_name=0x8e8b317 "logo-reverse.png", mime_types=0x101, > n_mime_types=2) > at endian.h:144 > 144 { > (gdb) list > 139 ((_x << 40) & ((__uint64_t)0xff << 48)) | ((_x << > 56))); > 140 } > 141 > 142 static __inline __uint32_t > 143 __bswap32(__uint32_t _x) > 144 { > 145 > 146 return (__byte_swap_int(_x)); > 147 } > 148 > > > kdbg reports that endian.h resides in /usr/include/machine. This looks like a stack overflow. Does increasing THR_STACK32_DEFAULT in /usr/src/lib/libpthread/thread/thr_private.h (maybe to (2 * 1024 * 1024)) then rebuilding libpthread help? What GTK+ theme are you using? Joe - -- PGP Key : http://www.marcuscom.com/pgp.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFec9vb2iPiv4Uz4cRAqG9AJ9aerGaeJeIbuwl1xfdz4HnSFPU6ACfS+g3 b8g/1qU+tMQpdZthqPT44t8= =8YNe -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4579CF70.3070703>