Firefox crash during dtrace attach under -CURRENT

[symbolics at gmx.com]

On Wed, Oct 23, 2013 at 10:59:02PM -0400, Mark Johnston wrote:
> On Wed, Oct 23, 2013 at 09:30:09PM +0100, symbolics at gmx.com wrote:
> > Hi,
> > 
> > http://dtrace.org/blogs/brendan/2011/02/11/dtrace-pid-provider-arguments/
> > 
> > I tried to follow some of the examples but I crash the Firefox process
> > each time. Sometimes DTrace manages to collect a little data before the
> > death.
> > 
> > [...]
> > 
> > Is this a known problem or should I send a PR?
> 
> Thanks for reporting this: I was able to reproduce the crash and managed
> to find a nasty pair of bugs. Could you test the patch below and let me
> know if it fixes the problem for you as well? If you see more crashes,
> please include the backtrace and signo from gdb again; it would likely
> be a different problem that needs to be debugged and fixed separately.

Hi Mark,

This helps but there still may be some issues. First time I used this
I found that when I killed the DTrace process Firefox went down too
with a SIGTRAP. I have a possibly unhelpful core from this:

Loaded symbols for /libexec/ld-elf.so.1
#0  0x000000080061d541 in r_debug_state (rd=0x801354480, m=0x7ffffb394f98)
    at /usr/home/dm/git/freebsd/libexec/rtld-elf/rtld.c:3491
3491    {
[New Thread 81b2da400 (LWP 100202/StreamTrans #12)]
[New Thread 81c4fb000 (LWP 100200/DOM Worker)]
[New Thread 81392b400 (LWP 100198/SSL Cert #2)]
[New Thread 816c62400 (LWP 100197/DNS Resolver #5)]
[New Thread 8160ccc00 (LWP 100196/Analysis Helper)]
[New Thread 8160cd400 (LWP 100195/Analysis Helper)]
[New Thread 8160cc400 (LWP 100194/Analysis Helper)]
[New Thread 8176f2800 (LWP 100187/DNS Resolver #4)]
[New Thread 8176f2400 (LWP 100186/DNS Resolver #3)]
[New Thread 819db1000 (LWP 100185/mozStorage #7)]
[New Thread 819dab000 (LWP 100183/mozStorage #6)]
[New Thread 8199bf000 (LWP 100182/mozStorage #5)]
[New Thread 8176e7c00 (LWP 100181/DNS Resolver #2)]
[New Thread 8176e8000 (LWP 100180/URL Classifier)]
[New Thread 8176ef000 (LWP 100179/mozStorage #4)]
[New Thread 81392a800 (LWP 100178/SSL Cert #1)]
[New Thread 818672400 (LWP 100177/Proxy Resolution)]
[New Thread 818671000 (LWP 100176/Cert Verify)]
[New Thread 8176e9c00 (LWP 100175/DNS Resolver #1)]
[New Thread 818671c00 (LWP 100174/Image Scaler)]
[New Thread 8176ed800 (LWP 100173/mozStorage #3)]
[New Thread 815ccd800 (LWP 100172/mozStorage #2)]
[New Thread 817051c00 (LWP 100171/mozStorage #1)]
[New Thread 815ee4800 (LWP 100170/localStorage DB)]
[New Thread 816c62000 (LWP 100167/ImageDecoder #1)]
[New Thread 801a04000 (LWP 100166/HTML5 Parser)]
[New Thread 8160c5c00 (LWP 100165/Cache I/O)]
[New Thread 815133800 (LWP 100163/DOM Worker)]
[New Thread 814eccc00 (LWP 100162/Timer)]
[New Thread 813845c00 (LWP 100161/Hang Monitor)]
[New Thread 813843400 (LWP 100160/JS Watchdog)]
[New Thread 813842c00 (LWP 100159/firefox)]
[New Thread 813842800 (LWP 100158/JS GC Helper)]
[New Thread 813842400 (LWP 100157/Socket Thread)]
[New Thread 801a09400 (LWP 100156/Gecko_IOThread)]
[New Thread 801a02400 (LWP 100079/firefox)]
(gdb) bt full
#0  0x000000080061d541 in r_debug_state (rd=0x801354480, m=0x7ffffb394f98)
    at /usr/home/dm/git/freebsd/libexec/rtld-elf/rtld.c:3491
No locals.
#1  0x000000000000000a in ?? ()
No symbol table info available.
#2  0x00000001013f2260 in ?? ()
No symbol table info available.
#3  0x00000008016b4a01 in _gmonparam () from /lib/libc.so.7
No symbol table info available.
#4  0x000000021a067540 in ?? ()
No symbol table info available.
#5  0x0000000000000020 in ?? ()
No symbol table info available.
#6  0x0000000800000002 in ?? ()
No symbol table info available.
#7  0x00007ffffb395000 in ?? ()
No symbol table info available.
#8  0x00000008013e2cb4 in __jemalloc_tcache_alloc_small (tcache=0x800636000, 
    size=<value optimized out>, zero=133) at tcache.h:323
        tbin = (tcache_bin_t *) 0x1a058b48197520a8
        ret = <value optimized out>
Previous frame inner to this frame (corrupt stack?)
Current language:  auto; currently minimal

Another time I saw the DTrace process exit by itself. The Firefox
process was still present but stuck in uwait with the UI completely
unresponsive. I tried reattaching to it but that didn't go anywhere.

Having said that, I can't seem to reproduce the crash consistently. I'll
keep playing with this and see if I can break it. Finally, I still see
the gelf_getehdr() error messages. If these aren't really errors, should
they be announced?

By the way, the DTrace command I used for testing was:

 pid$target::malloc:entry { @ = quantize(arg0); }
 profile-5sec { printa(@); }

Thanks for your work!

--sym