Date: Sun, 27 Oct 2013 15:59:24 -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: <20131027195924.GA7526@charmander.uwaterloo.ca> 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: 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131027195924.GA7526>