Date: Fri, 25 Oct 2013 11:09:23 -0400 From: Mark Johnston <markj@freebsd.org> To: symbolics@gmx.com Cc: dtrace@freebsd.org Subject: Re: Firefox crash during dtrace attach under -CURRENT Message-ID: <20131025150923.GA1906@charmander> In-Reply-To: <20131025104706.GB1705@lemon> References: <20131023203009.GA92945@lemon> <20131024025902.GA2286@charmander> <20131025104706.GB1705@lemon>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 25, 2013 at 11:47:06AM +0100, symbolics@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@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 > This is a function in rtld that's intended specifically for setting breakpoints prior to running init functions and main(); it's used by dtrace(1) too. I haven't seen this crash myself, but I'll see if I can trigger it once I have some time to work on this a bit more. > [...] > > 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. It seems I can reproduce this reliably by opening facebook while dtrace is attached. I'll try and figure out what's going on, thanks. > > 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? Probably not. :) > > By the way, the DTrace command I used for testing was: > > pid$target::malloc:entry { @ = quantize(arg0); } > profile-5sec { printa(@); } > > Thanks for your work! No problem. Thanks for reporting these issues. -Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131025150923.GA1906>