Date: Fri, 25 Oct 2013 11:47:06 +0100 From: symbolics@gmx.com To: dtrace@freebsd.org Subject: Re: Firefox crash during dtrace attach under -CURRENT Message-ID: <20131025104706.GB1705@lemon> In-Reply-To: <20131024025902.GA2286@charmander> References: <20131023203009.GA92945@lemon> <20131024025902.GA2286@charmander>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131025104706.GB1705>