Firefox crash during dtrace attach under -CURRENT

[Mark Johnston]

On Fri, Oct 25, 2013 at 11:47:06AM +0100, symbolics at gmx.com wrote:
> 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:

Just FYI, I've committed the push %rbp emulation fix as r257143:
http://svnweb.freebsd.org/base?view=revision&revision=257143

> 
> 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
> _______________________________________________
> freebsd-dtrace at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace
> To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe at freebsd.org"