896410 - GonkSensor triggers a MOZ_CRASH when loading a web from Gaia Browser app

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect)

Description

[Fernando Jiménez Moreno [:ferjm]]

Not sure how is this related with the Gaia Browser app... Anyway, I've been seeing this crash a few times with Birch and Gaia master.

loading about:blank, 1
loading http://ferjm.github.io/simplepayprovider/page1.html, 1
[New Thread 252.331]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 252.331]
0x40d5cc8e in nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyElements<unsigned int> >::IncrementLength (this=0x49677cf0, n=<value optimized out>)
    at ../../../dist/include/nsTArray.h:427
427	        MOZ_CRASH();
(gdb) bt
#0  0x40d5cc8e in nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyElements<unsigned int> >::IncrementLength (this=0x49677cf0, 
    n=<value optimized out>) at ../../../dist/include/nsTArray.h:427
#1  0x40e2f95c in AppendElements<float> (this=0x49677cf0, item=@0x450ff688) at ../dist/include/nsTArray.h:1190
#2  nsTArray_Impl<float, nsTArrayInfallibleAllocator>::AppendElement<float> (this=0x49677cf0, item=@0x450ff688) at ../dist/include/nsTArray.h:1203
#3  0x40e2fbc0 in SensorRunnable () at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/hal/gonk/GonkSensor.cpp:137
#4  PollSensors () at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/hal/gonk/GonkSensor.cpp:202
#5  0x40d7042c in DispatchToFunction<void (*)()> (this=0x49677cf0) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/tuple.h:439
#6  RunnableFunction<void (*)(), Tuple0>::Run (this=0x49677cf0) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/task.h:415
#7  0x40ff9e08 in MessageLoop::RunTask (this=0x450ffde8, task=0x3e57bf0e)
    at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:337
#8  0x40ffabee in MessageLoop::DeferOrRunPendingTask (this=0x49677cf0, pending_task=<value optimized out>)
    at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:345
#9  0x40ffb7b4 in MessageLoop::DoWork (this=0x450ffde8) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:445
#10 0x40ffba44 in base::MessagePumpDefault::Run (this=0x44f710e0, delegate=0x450ffde8)
    at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_pump_default.cc:23
#11 0x40ff9dcc in MessageLoop::RunInternal (this=0x450ffde8) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:219
#12 0x40ff9e4a in MessageLoop::RunHandler (this=0x450ffde8) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:212
#13 MessageLoop::Run (this=0x450ffde8) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/message_loop.cc:186
#14 0x40ffcc26 in base::Thread::ThreadMain (this=0x44f447f0) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/thread.cc:160
#15 0x40ffd828 in ThreadFunc (closure=0x1) at /Volumes/SSD/dev/mozilla/mozilla-birch_/birch/ipc/chromium/src/base/platform_thread_posix.cc:39
#16 0x4010ce18 in __thread_entry (func=0x40ffd821 <ThreadFunc>, arg=0x44f447f0, tls=<value optimized out>) at bionic/libc/bionic/pthread.c:217
#17 0x4010c96c in pthread_create (thread_out=<value optimized out>, attr=0xbef573d8, start_routine=0x40ffd821 <ThreadFunc>, arg=0x44f447f0)
    at bionic/libc/bionic/pthread.c:357
#18 0x00000000 in ?? ()
(gdb) l
422	  // always be 0.
423	  void IncrementLength(uint32_t n) {
424	    if (mHdr == EmptyHdr()) {
425	      if (MOZ_UNLIKELY(n != 0)) {
426	        // Writing a non-zero length to the empty header would be extremely bad.
427	        MOZ_CRASH();
428	      }
429	    } else {
430	      mHdr->mLength += n;
431	    }

Comment 1

[Dave Hylands [:dhylands]]

This looks very much like bug 694594 manifesting itself in InfallibleTArray rather than js::Vector.

The code path we take call AppendElement, which calls AppendElements with n=1. We crash due to n==0, which implies badly generated code.

My debug build (debug builds don't manifest the problem) hits a different assert. I'm going to do a release build and see if I hit it.

Comment 2

[Dave Hylands [:dhylands]]

In my release build (on my unagi) I tried to load

http://ferjm.github.io/simplepayprovider/page1.html

[JavaScript Error: "not well-formed" {file: "app://browser.gaiamobile.org/js/init.json" line: 1 column: 1 source: "{"}]

My init.json looks like:

{
  "000000": {
    "bookmarks": []
  }
}

Comment 3

[Dave Hylands [:dhylands]]

I take back comment 1.

It looks like the only way that this can fail is if the allocation of mHdr fails.

It would be really useful to have the output of logcat that corresponds to one of these failures.

Comment 4

[Jason Smith [:jsmith]]

Haven't seen this during daily test runs for a while, so pulling from tracker.

Comment 5

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. 

If I incorrectly invalidated something, please let me know.

Comment 6

[Firefox Bug Husbandry Bot]

Bulk correction of resolution of B2G bugs to INCOMPLETE.