1016512 - Crash in MOZ_PNG_read_filt_row_a while stability testing

Status: RESOLVED DUPLICATE of bug 964537

(Core :: JavaScript Engine, defect)

Description

[Greg Grisco]

Attachment: decoded minidump of crash

After running stability scripts to test call and multimedia functionality, minidumps generated with crash signature:

[@ ? | MOZ_PNG_read_filt_row_a | ? | js::LookupNameNoGC(JSContext*, js::PropertyName*, JSObject*, JSObject**, JSObject**, js::Shape**) ]

Comment 1

[Greg Grisco]

Attachment: EXTRA file attachment (plus some logs)

Comment 2

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.109
Moz BuildID: 20140522000200
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=c1b9b2a8cf2a852384f9ae408117303fb35932ef

Comment 3

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8226
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.109
Moz BuildID: 20140522000200
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=c1b9b2a8cf2a852384f9ae408117303fb35932ef

Comment 4

[Preeti Raghunath(:Preeti)]

Is this related or dependent to bug 1008791?

Comment 5

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.112
Moz BuildID: 20140524000202
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=8f4201a44676eb70926a3d2645d94bf92fcd6718
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=c69048b9a3fcacc456f281db08a5e6162655ecec

Comment 6

[Preeti Raghunath(:Preeti)]

Naveed

Please weigh in here.

Comment 7

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.114
Moz BuildID: 20140528000201
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=cd595be0a8e975559e8938830df5face89bec3e8
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=d591b0c691da6847dcb9a4f626211b597e8807fe

Comment 8

[Naveed Ihsanullah [:naveed]]

Do we know the frequency of the crash (is it 100%)? Do we have STR the bug? 

What is the stability testing framework? Is that something we have to so we can replicate the testing locally? 

A one off JavaScript bug (or infrequent) like 1008791 are not actionable. If it is a regression that is useful information. If we have steps to reproduce and hardware to reproduce the bug that is very helpful to. 

Adding Nicolas. He may see something in the stack.

Comment 9

[Glenn Randers-Pehrson]

The stack says the ARM-NEON optimizations are not being used.  Otherwise the crash would have occurred in  MOZ_PNG_read_filt_row_a3_neon in arm/filter_neon_intrinsics.c instead.  There's nothing wrong with that; it just means the particular CPU doesn't support the optimizations, and the configure system didn't select them.

Comment 10

[Nicolas B. Pierron [:nbp]]

I think the crash is in neither in MOZ_PNG_read_filt_row_a nor in js::LookupNameNoGC.
Apparently the stack unwinder is able to walk the stack only after

 4  libxul.so!Interpret [Interpreter.cpp : 3483 + 0x5]
 5  libxul.so!js::RunScript [Interpreter.cpp : 423 + 0x7]
 6  libxul.so!js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct) [Interpreter.cpp : 430 + 0x5]

which means that the code which is crashing is likely under some Jit code.

From what I understand from the logcat (attachement 8429457), this is a dual sim phone which is receiving a lot of phone call on the first sim and a few on the second one.  So if this is a compilation issue, we might try enabling --ion-eager on the phone and call it multiple times to see if we can reproduce this issue.

I will need extra SIM cards for testing that.

Q: I see that MOZ_PNG was found on the stack, do you have pictures for the contacts which are calling in?  I don't know if this matters yet, but this might play some role in reproducing this issue.

By the way, thanks for the logcat :), without it we would have just no starting point.

Comment 11

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.118
Moz BuildID: 20140601000202
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=ba8d7ef46cadf5d66d189b0b036d0f2e936bece0
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=963313cd69a0de0b8712824b1778408da22f51fe

Comment 12

[Greg Grisco]

(In reply to Nicolas B. Pierron [:nbp] from comment #10)

> Q: I see that MOZ_PNG was found on the stack, do you have pictures for the
> contacts which are calling in?  I don't know if this matters yet, but this
> might play some role in reproducing this issue.

No, unfortunately we don't have pictures or video.  Capturing this might not be feasible either since some of the crashes occur while running scripts over the weekend.

> By the way, thanks for the logcat :), without it we would have just no
> starting point.

If there are other log messages that we can add to aid debugging, please let us know.

Right now, we are wondering whether the use of select() and FD_SET that we have found to cause stack corruption (see bug 1001897) due to large number of fds being used could also be the problem here.

Comment 13

[Nicolas B. Pierron [:nbp]]

(In reply to Greg Grisco from comment #12)
> (In reply to Nicolas B. Pierron [:nbp] from comment #10)
> 
> > Q: I see that MOZ_PNG was found on the stack, do you have pictures for the
> > contacts which are calling in?  I don't know if this matters yet, but this
> > might play some role in reproducing this issue.
> 
> No, unfortunately we don't have pictures or video.  Capturing this might not
> be feasible either since some of the crashes occur while running scripts
> over the weekend.

My question was more about the content of the phone, do we have a picture associated to the phone number which is calling in?  Is this a png / jpg, or we do not have any picture?

As I am supposing that this might be related to Ion's compilation I will try to reproduce this by asking the compiler to compile sooner than after hundreds of iterations.  I will test it tomorrow, I just got some the SIM cards today.

Comment 14

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.119
Moz BuildID: 20140602000203
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=ba8d7ef46cadf5d66d189b0b036d0f2e936bece0
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=080d2fc00828113314448f5488ac865e988b7535

Comment 15

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #10)
> I think the crash is in neither in MOZ_PNG_read_filt_row_a nor in
> js::LookupNameNoGC.
> Apparently the stack unwinder is able to walk the stack only after
> 
>  4  libxul.so!Interpret [Interpreter.cpp : 3483 + 0x5]
>  5  libxul.so!js::RunScript [Interpreter.cpp : 423 + 0x7]
>  6  libxul.so!js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
> [Interpreter.cpp : 430 + 0x5]
> 
> which means that the code which is crashing is likely under some Jit code.
> 
> From what I understand from the logcat (attachement 8429457), this is a dual
> sim phone which is receiving a lot of phone call on the first sim and a few
> on the second one.  So if this is a compilation issue, we might try enabling
> --ion-eager on the phone and call it multiple times to see if we can
> reproduce this issue.

So far I tried with version 1.3 which is shipped by default on the flame. and I was not able to reproduce this issue.  I followed the following protocol for testing:

- Before calling the device, I added the following line to /system/b2g/defaults/pref/user.js

> perf("javascript.options.ion.unsafe_eager_compilation", true);

- After rebooting the phone.
- Take a camera picture and set it as the contact image of the caller.
- Make this phone ring by calling it. (x10)

Normally, only a few iterations are enough to catch failures with ion-eager enabled, is this is a deterministic error.

Later, I will try flashing 1.4 images on the flame to see if this is an issue specific to Gecko 29/30.

[1] http://dxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#1572

Comment 16

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.121
Moz BuildID: 20140604000202
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=0c16adced7c51f795ef250aebe184f60b6a9b987
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=157a45f1fa280296dc9204de6def0b5b370ed2bd

Comment 17

[Greg Grisco]

(In reply to cafbot (PoC: ggrisco) from comment #16)
> Crash observed on: 
> 
> Device: msm8610
> Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.121
> Moz BuildID: 20140604000202
> B2G Version: 1.4
> Gecko Version: 30.0
> Gaia: 
> http://git.mozilla.org/?p=releases/gaia.git;a=commit;
> h=0c16adced7c51f795ef250aebe184f60b6a9b987
> Gecko:
> http://git.mozilla.org/?p=releases/gecko.git;a=commit;
> h=157a45f1fa280296dc9204de6def0b5b370ed2bd

We observed this latest crash using same scneario but without any calls or sms.

Comment 18

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.124
Moz BuildID: 20140607000201
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=0c3321207bfad3d6ee936f3ee8d87e5d075e6ca9
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=1dd8365f64f3131bc20e44172b54a81e9c9572ce

Comment 19

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #15)
> Later, I will try flashing 1.4 images on the flame to see if this is an
> issue specific to Gecko 29/30.

Ok, I've tried flashing a v1.4 from pvt builds on a Flame device which has 2 SIMs in it.

I've the eager compilation flag for both "ion" and "baselinejit".  I am unable to reproduce any crash just by opening random applications, browsing a list of 500 contacts.

I cannot try making phone calls yet, as this implies that the SIM cards are recognized, and apparently the RIL issue is not yet fixed for the flame in v1.4.  But as Greg mentioned, these issues are reproducible without making any use of the RIL.

Comment 20

[Nicolas B. Pierron [:nbp]]

Attachment: raw-stack

I managed to reproduce a similar issue "once" on a flame which memory is limited to 256mb by doing some hand fuzzing for 10 minutes.  Sadly the build that I have does not have any symbols, so I only have a stack scanning, which highlight almost the same stack scanning.

This is not exactly a crash as of now, but more an infinite loop, where I had to C^c to halt in it.  Currently, if I resume the execution I am stuck in a spin-lock of a Mutex.

(gdb) x /128i 0xb4c42276
   0xb4c42276:  ldrex   r3, [r0]     ; atomic load of [r0]
   0xb4c4227a:  adds    r1, r3, #1
   0xb4c4227c:  strex   r2, r1, [r0] ; set r2 to 1, if r1 is stored in [r0]
                                     ; when this core has an exclusive view
                                     ; over the memory of r0
   0xb4c42280:  cmp     r2, #0
=> 0xb4c42282:  bne.n   0xb4c42276

But this seems to be a limitation of ARM instruction set.  As gdb is trying to inspect memory, and thus prevent the memory from being exclusive to the inspected program.

Setting a breakpoint after the spin-lock cause the program to crash later in some code which is not produced by the ARM MacroAssembler. (as we only produce thumb code)  Strangely th breakpoint is not hit, even if we remained on the main thread of the main process.

Looking at the stack, I do not recognize any IonMonkey / Baseline frame call which would have pushed JSValues on the stack.

Comment 21

[Nicolas B. Pierron [:nbp]]

Attachment: Disable All the JITs.

This patch is used to disable all the Jit all the time, this would cause all
the JavaScript to run in the interpreter, which might cause some slow-down
in javascript heavy pages.

This patch is based on top of the latest commit of b2g30_v1_4.

Comment 22

[Nicolas B. Pierron [:nbp]]

I am currently working on an additional patch to add JS assertions on optimized builds, the patch is being checked on our try server to verify that dummy assertion are working as expected on optimized builds.

https://tbpl.mozilla.org/?tree=Try&rev=4674904d6417

Comment 23

[Nicolas B. Pierron [:nbp]]

Attachment: Assembly & Stack of the failing functions.

This is what I've manually extracted so far. I will try to give a name to these functions based on the crash reporter symbols.

https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-b2g30_v1_4-flame-eng/2014/06/2014-06-16-00-02-02/

Comment 24

[Greg Grisco]

Are you recommending that we attempt to reproduce this crash with attachment 8441342 [details] [diff] [review]?

Comment 25

[Chris Peterson [:cpeterson]]

Greg: yes. We discussed Nicolas' "Disable All the JITs" patch in yesterday's meeting. Nicolas and Jason hope that, by disabling the JITs, the JS interpreter will produce better crash stack traces.

Nicolas' second patch (to enable JS assertions in optimized builds) is also intended to be run with your tests.

Comment 26

[Nicolas B. Pierron [:nbp]]

Attachment: Enable JS assertions in optimized builds.

This patch hack the configure system such as we accept a new environment
variable which turn on --enable-debug during the build of the JavaScript
engine.

Comment 27

[Nicolas B. Pierron [:nbp]]

Comment on attachment 8441663 [details] [diff] [review]
Enable JS assertions in optimized builds.

Side note about this patch, even if I made a build for a flame which is including this patch, I have not yet tested it on a devide as I am trying to get the most out of the current session where I have a gdb hooked on this crash.

I am trying to figure out how to map the crash-stat symbols into a gdb session, sadly it does not seems to list which libraries are loaded.

ted: Do you have any suggestion on how I can add the symbols or map the stack addresses of attachment 8441498 [details] to any of the symbols of comment 23's build link?

Comment 28

[(not currently active) Ted Mielczarek]

There's no way to load .sym files into GDB. If you have library load addresses you can fairly easily look up the functions by RVA. The script we use for symbolicating assertion stacks using Breakpad symbols might be useful as a guide:
http://mxr.mozilla.org/mozilla-central/source/tools/rb/fix_stack_using_bpsyms.py

Comment 29

[Nicolas B. Pierron [:nbp]]

Attachment: /proc/<pid>/maps with function addresses.

Ok, I don't know why I have no additional symbols, or why we had no additional symbols, but this stack trace seems to be that the libxul is calling libnss3 with pointer which are targeting an unmapped location.

I will see if I can find symbol names based on the relative offset of the functions within each mapped sections.

Comment 30

[Nicolas B. Pierron [:nbp]]

Here is a converted stack trace, that gdb is unable to provide to me.  This stack is still a bit weird as gcc is doing some tail call optimization, which appear as the dump of r3 does not match inner0 address.  I will try to find out what is/are the missing frames between inner0 and inner1.

inner0: SECITEM_FreeItem_Util
     -- security/nss/lib/util/secitem.c:294
     -- ?? (tail call)
inner1: ?::assign_with_AddRef(?)
inner2: nsThread::ProcessNextEvent(bool, bool*)
     -- objdir-gecko/xpcom/threads/../../dist/include/nsCOMPtr.h:698
     -- xpcom/threads/nsThread.cpp:667  [1]
inner3: NS_ProcessNextEvent(nsIThread*, bool)
inner4: mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*)
inner5: MessageLoop::RunInternal()
inner6: MessageLoop::Run()
inner7: nsBaseAppShell::Run()
inner8: nsAppStartup::Run()

[1] http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/fab72d8aa2e0/xpcom/threads/nsThread.cpp#l667

Comment 31

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

(In reply to Nicolas B. Pierron [:nbp] from comment #27)
> Comment on attachment 8441663 [details] [diff] [review]
> Enable JS assertions in optimized builds.
> 
> Side note about this patch, even if I made a build for a flame which is
> including this patch, I have not yet tested it on a devide as I am trying to
> get the most out of the current session where I have a gdb hooked on this
> crash.
> 
> I am trying to figure out how to map the crash-stat symbols into a gdb
> session, sadly it does not seems to list which libraries are loaded.
> 
> ted: Do you have any suggestion on how I can add the symbols or map the
> stack addresses of attachment 8441498 [details] to any of the symbols of
> comment 23's build link?

This patch (attachment 8441663 [details] [diff] [review]) prevents device to boot. Should I apply patch from only #comment 21 ? 

Please confirm us list of patches which needs to be tested in our stability testing.

Comment 32

[Nicolas B. Pierron [:nbp]]

(In reply to Tapas Kumar Kundu from comment #31)
> (In reply to Nicolas B. Pierron [:nbp] from comment #27)
> > Comment on attachment 8441663 [details] [diff] [review]
> > Enable JS assertions in optimized builds.
> > 
> > Side note about this patch, even if I made a build for a flame which is
> > including this patch, I have not yet tested it on a devide as I am trying to
> > get the most out of the current session where I have a gdb hooked on this
> > crash.
> 
> This patch (attachment 8441663 [details] [diff] [review]) prevents device to
> boot. Should I apply patch from only #comment 21 ? 

Is an assertion failing or it is just to slow to boot before any of the timeout of the tests?

> Please confirm us list of patches which needs to be tested in our stability
> testing.

Yes, please proceed with comment 21 in the mean time.  At the moment I do not want to lose this gdb session, so I cannot test the image of the flame that I made with attachement 8441663.  I will try to make a new patch to enable assertions, and ensure that it boots correctly.

Comment 33

[cafbot (PoC: ggrisco)]

Crash observed on: 

Device: msm8610
Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.130
Moz BuildID: 20140614000202
B2G Version: 1.4
Gecko Version: 30.0
Gaia:  http://git.mozilla.org/?p=releases/gaia.git;a=commit;h=164644d91290708a71436dfdf4301e33b92e2c77
Gecko: http://git.mozilla.org/?p=releases/gecko.git;a=commit;h=89e926ba3a65372a74d72c30a8773081820cccbb

Comment 34

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #30)
> Here is a converted stack trace, that gdb is unable to provide to me.  This
> stack is still a bit weird as gcc is doing some tail call optimization,
> which appear as the dump of r3 does not match inner0 address.  I will try to
> find out what is/are the missing frames between inner0 and inner1.
> 
> inner0: SECITEM_FreeItem_Util
>      -- security/nss/lib/util/secitem.c:294
>      -- ?? (tail call)
> inner1: ?::assign_with_AddRef(?)
> inner2: nsThread::ProcessNextEvent(bool, bool*)
>      -- objdir-gecko/xpcom/threads/../../dist/include/nsCOMPtr.h:698
>      -- xpcom/threads/nsThread.cpp:667  [1]

I have tried to understand the relation between inner1 and inner0 and find what virtual function we are calling from inner1.  Sadly I failed to get a good understanding of it.

By following instructions from just above the call made from inner2, into inner1, and looking at the value spilled on the stack, I found that the supposed caller (from inner1) should have been an Atomic increment from mfbt.

(gdb) p /x *(**(0xaf2af6e0 + 8) + 4)
$14 = 0xb51d113d

; ??
(gdb) x/20i *(**(0xaf2af6e0 + 8) + 4)
   0xb51d113d:  sub.w   r0, r0, #472    ; 0x1d8
   0xb51d1141:  b.w     0xb51d112c

; ????
(gdb) x/20i 0xb51d112c               
   0xb51d112c:  add.w   r0, r0, #496    ; 0x1f0
   0xb51d1130:  b.w     0xb4c42272

; Atomic32::operator++()
(gdb) x/20i 0xb4c42272
   0xb4c42272:  dmb     sy
   0xb4c42276:  ldrex   r3, [r0]
   0xb4c4227a:  adds    r1, r3, #1
   0xb4c4227c:  strex   r2, r1, [r0]
   0xb4c42280:  cmp     r2, #0
   0xb4c42282:  bne.n   0xb4c42276
   0xb4c42284:  dmb     sy
   0xb4c42288:  adds    r0, r3, #1
   0xb4c4228a:  bx      lr

; value of the refcount
(gdb) p /x *(*(0xaf2af6e0 + 8) - 472 + 496)
$19 = 0x14

Sadly, even if this match what we are expecting to see on the stack, this does not solve the tail call issue, as the instruction at 0xb4c4228a is returning to inner1.  Marty suggested that the tail-call branch at the end of inner1 might be the one which is making the call to inner0 as the lr register is not clobbered.

; ?::assign_assuming_AddRef(?)
(gdb) x/20i 0xb4c44c96
   0xb4c44c96:  push    {r3, lr}
   0xb4c44c98:  ldr     r3, [r0, #0]
   0xb4c44c9a:  str     r1, [r0, #0]
   0xb4c44c9c:  cbz     r3, 0xb4c44ca6
   0xb4c44c9e:  ldr     r2, [r3, #0]
   0xb4c44ca0:  mov     r0, r3
   0xb4c44ca2:  ldr     r2, [r2, #8]
   0xb4c44ca4:  blx     r2
   0xb4c44ca6:  pop     {r3, pc}

But this hypothesis sounds unlikely, as the "blx r2" instruction would update the lr register and inner0 would see a different value than the return address within inner1.

Comment 35

[Chris Peterson [:cpeterson]]

Inder says their device fails to boot when the "Enable JS assertions in optimized builds" patch is applied. The boot screen is black and there is no log output, so they don't know whether this is an assertion failure or just a very slow boot that never completes.

They are now testing the "Disable All the JITs" patch.

nbp says he will be retest the assertion patch tomorrow.

Comment 36

[Inder]

> there is no log output
Correction: we did get some logcat output but not sure how helpful that is.
Tapas, please attach the logcat log.

Comment 37

[Tapas[:tkundu on #b2g/gaia/memshrink/gfx] (always NI me)]

Attachment: js_assertion_boot_failure.txt

(In reply to Inder from comment #36)
> > there is no log output
> Correction: we did get some logcat output but not sure how helpful that is.
> Tapas, please attach the logcat log.

here it is.

Comment 38

[Nicolas B. Pierron [:nbp]]

(In reply to Tapas Kumar Kundu from comment #37)
> Created attachment 8442468 [details]
> js_assertion_boot_failure.txt
> 
> (In reply to Inder from comment #36)
> > > there is no log output
> > Correction: we did get some logcat output but not sure how helpful that is.
> > Tapas, please attach the logcat log.
> 
> here it is.

This is strange, I do no see any assertion failure reported in the logcat, which should be the case in case of assertion failure (as stderr is forwarded to the logcat).

So the boot issue is not caused by an assertion failure (which is good).

Comment 39

[Nicolas B. Pierron [:nbp]]

(In reply to cafbot (PoC: ggrisco) from comment #33)
> Crash observed on: 
> 
> Device: msm8610
> Gonk Version: AU_LINUX_GECKO_B2G_KK_3.5.01.04.00.113.130
> Moz BuildID: 20140614000202
> B2G Version: 1.4
> Gecko Version: 30.0
> Gaia: 
> http://git.mozilla.org/?p=releases/gaia.git;a=commit;
> h=164644d91290708a71436dfdf4301e33b92e2c77
> Gecko:
> http://git.mozilla.org/?p=releases/gecko.git;a=commit;
> h=89e926ba3a65372a74d72c30a8773081820cccbb

Did this failure happen with the patch from comment 21?

Comment 40

[Inder]

With the fix from bug 964537, this issue does not reproduce. Marking this as a duplicate.

Comment 41

[Dave Hylands [:dhylands]]

This hardly looks like a duplicate. The stack trace bears no resemblence.

I think that there might be a coincidence, or perhaps a code shift, but not a duplicate.