ports/105589: Firefox 2.0 segfaults when saving more than one file per session

[Micah]

The following reply was made to PR ports/105589; it has been noted by GNATS.

From: Micah <micahjon at ywave.com>
To: Joe Marcus Clarke <marcus at marcuscom.com>
Cc: gnome at freebsd.org,  bug-followup at freebsd.org
Subject: Re: ports/105589: Firefox 2.0 segfaults when saving more than one
 file per session
Date: Fri, 08 Dec 2006 13:05:34 -0800

 Joe Marcus Clarke wrote:
 > -----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
 
 Upping THR_STACK32_DEFAULT to 2* doesn't seem to help.
 
 I'm using rpanther2 as my GTK theme, but it happens even if my 
 .gtkrc-2.0 doesn't specify any theme.
 
 I've noticed a slight timing aspect to the crash. If I go slow, it 
 crashes on the second save. If I go fast, it crashes on the third save. 
 Here's the cycle I follow: right click on image, press v, enter, enter, 
 right click on same image and repeat.
 
 Pressing enter enter before the dialog shows results in a different, 
 probably unrelated, crash. If you think this is related I can include 
 the stack trace of that too.
 
 Gtk-ERROR **: file gtkfilechooserdefault.c: line 7772 
 (gtk_file_chooser_default_should_respond): assertion failed: (path != NULL)
 aborting...
 Abort trap (core dumped)
 
 
 - Micah