1341084 - getHistogramById("something").add.apply(null, [1]) locks up xpcshell tests

Status: NEW

(Toolkit :: Telemetry, defect, P3)

Description

[Alessio Placitelli [:Dexter]]

In bug 1321349 we found that calling the following code in a xpcshell test locks it up.

> Telemetry.getHistogramById("TELEMETRY_TEST_EXPONENTIAL").add.apply(null, [1]);

The Telemetry C++ code doesn't get called [1] and nothing really happens (no log output or error) until the test times out.

[1] - http://searchfox.org/mozilla-central/rev/12cf11303392edac9f1da0c02e3d9ad2ecc8f4d3/toolkit/components/telemetry/TelemetryHistogram.cpp#1451

Comment 1

[Georg Fritzsche [:gfritzsche]]

Have you attached a debugger to get a stacktrace at the time of the hang?
(C++ or Python debugger, depending on whats going on)

Comment 2

[Benjamin Smedberg]

Or just step through ;-)

Comment 3

[Alessio Placitelli [:Dexter]]

Using GDB, CTRL+C'ing and then calling 'bt', I was able to get this:

> (gdb) bt
> #0  0x00007fffeff3cb5d in poll () at ../sysdeps/unix/syscall-template.S:84
> #1  0x00007ffff3f78fcb in PollWrapper(GPollFD*, guint, gint) (ufds=0x7fffdef832c0, nfsd=3, timeout_=-1)
>     at /home/dexter/mozilla-central/widget/gtk/nsAppShell.cpp:42
> #2  0x00007fffee1ab38c in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007fffee1ab49c in g_main_context_iteration () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #4  0x00007ffff3f79033 in nsAppShell::ProcessNextNativeEvent(bool) (this=<optimized out>, mayWait=<optimized out>)
>     at /home/dexter/mozilla-central/widget/gtk/nsAppShell.cpp:270
> #5  0x00007ffff3f4a945 in nsBaseAppShell::DoProcessNextNativeEvent(bool) (this=this@entry=0x7fffe0c23390, mayWait=<optimized out>)
>     at /home/dexter/mozilla-central/widget/nsBaseAppShell.cpp:138
> #6  0x00007ffff3f4e3ad in nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (this=0x7fffe0c23390, thr=0x7fffe63cb160, mayWait=true)
>     at /home/dexter/mozilla-central/widget/nsBaseAppShell.cpp:289
> #7  0x00007ffff21ce2e7 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7fffe63cb160, aMayWait=<optimized out>, aResult=0x7fffffffa898)
>     at /home/dexter/mozilla-central/xpcom/threads/nsThread.cpp:1225
> #8  0x00007ffff21d875a in NS_InvokeByIndex () at /home/dexter/mozilla-central/xpcom/reflect/xptcall/md/unix/xptcinvoke_asm_x86_64_unix.S:88
> #9  0x00007ffff2a554fb in CallMethodHelper::Call() (this=0x7fffffffa838) at /home/dexter/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:2010
> #10 0x00007ffff2a554fb in CallMethodHelper::Call() (this=0x7fffffffa838) at /home/dexter/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1329
> #11 0x00007ffff2a460a6 in XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) (
>     ccx=..., mode=mode@entry=XPCWrappedNative::CALL_METHOD) at /home/dexter/mozilla-central/js/xpconnect/src/XPCWrappedNative.cpp:1296
> #12 0x00007ffff2a49850 in XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) (cx=0x7fffe465c000, argc=<optimized out>, vp=<optimized out>)
>     at /home/dexter/mozilla-central/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:983
> #13 0x000000f9019eed7f in  ()
> #14 0x0000000000000008 in  ()
> #15 0x00007fffffffaaf8 in  ()
> #16 0x00007fffdee551f0 in  ()
> #17 0x0000000000000000 in  ()

On the other hand, stepping through the code after placing a breakpoint, it seems like it starts continuously calling the add() over and over. I'll provided a more detailed report as soon as bug 1321349 lands.

Comment 4

[Georg Fritzsche [:gfritzsche]]

I ran into a similar xpcshell hang.
My problem turned out that we returned false from a JSNative function without reporting an error to JS.
This should be worth checking here too, see the documentation:
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JSNative