Closed
Bug 1016512
Opened 10 years ago
Closed 10 years ago
Crash in MOZ_PNG_read_filt_row_a while stability testing
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 964537
blocking-b2g | 1.4+ |
People
(Reporter: ggrisco, Assigned: nbp)
References
Details
(Keywords: crash, Whiteboard: [caf priority: p1][CR 670060][b2g-crash])
Attachments
(8 files)
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**) ]
Reporter | ||
Comment 1•10 years ago
|
||
Updated•10 years ago
|
Component: General → JavaScript Engine
Keywords: crash
Product: Firefox OS → Core
Whiteboard: [CR 670060] → [CR 670060][b2g-crash]
Version: unspecified → 30 Branch
Comment 2•10 years ago
|
||
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•10 years ago
|
||
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•10 years ago
|
||
Is this related or dependent to bug 1008791?
Comment 5•10 years ago
|
||
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 7•10 years ago
|
||
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•10 years ago
|
||
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.
Flags: needinfo?(nihsanullah) → needinfo?(nicolas.b.pierron)
Comment 9•10 years ago
|
||
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.
Assignee | ||
Comment 10•10 years ago
|
||
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.
Flags: needinfo?(ggrisco)
Updated•10 years ago
|
Whiteboard: [CR 670060][b2g-crash] → [caf priority: p1][CR 670060][b2g-crash]
Comment 11•10 years ago
|
||
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
Reporter | ||
Comment 12•10 years ago
|
||
(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.
Flags: needinfo?(ggrisco)
Assignee | ||
Comment 13•10 years ago
|
||
(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•10 years ago
|
||
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
Assignee | ||
Comment 15•10 years ago
|
||
(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•10 years ago
|
||
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
Updated•10 years ago
|
blocking-b2g: 1.4? → 1.4+
Reporter | ||
Comment 17•10 years ago
|
||
(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•10 years ago
|
||
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
Updated•10 years ago
|
Assignee: nobody → nicolas.b.pierron
Assignee | ||
Comment 19•10 years ago
|
||
(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.
Flags: needinfo?(nicolas.b.pierron)
Assignee | ||
Comment 20•10 years ago
|
||
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.
Assignee | ||
Comment 21•10 years ago
|
||
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.
Attachment #8441342 -
Flags: feedback?
Assignee | ||
Updated•10 years ago
|
Attachment #8441342 -
Flags: feedback? → feedback?(ggrisco)
Assignee | ||
Comment 22•10 years ago
|
||
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
Assignee | ||
Comment 23•10 years ago
|
||
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/
Reporter | ||
Comment 24•10 years ago
|
||
Are you recommending that we attempt to reproduce this crash with attachment 8441342 [details] [diff] [review]?
Flags: needinfo?(nicolas.b.pierron)
Comment 25•10 years ago
|
||
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.
Flags: needinfo?(nicolas.b.pierron)
Assignee | ||
Comment 26•10 years ago
|
||
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.
Assignee | ||
Comment 27•10 years ago
|
||
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?
Flags: needinfo?(ted)
Comment 28•10 years ago
|
||
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
Flags: needinfo?(ted)
Assignee | ||
Comment 29•10 years ago
|
||
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.
Assignee | ||
Comment 30•10 years ago
|
||
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
(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.
Flags: needinfo?(nicolas.b.pierron)
Assignee | ||
Comment 32•10 years ago
|
||
(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.
Flags: needinfo?(nicolas.b.pierron)
Comment 33•10 years ago
|
||
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
Assignee | ||
Comment 34•10 years ago
|
||
(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•10 years ago
|
||
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•10 years ago
|
||
> 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.
Flags: needinfo?(tkundu)
(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.
Flags: needinfo?(tkundu)
Assignee | ||
Comment 38•10 years ago
|
||
(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).
Assignee | ||
Comment 39•10 years ago
|
||
(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?
Flags: needinfo?(ggrisco)
Comment 40•10 years ago
|
||
With the fix from bug 964537, this issue does not reproduce. Marking this as a duplicate.
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(ggrisco)
Resolution: --- → DUPLICATE
Comment 41•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
Attachment #8441342 -
Flags: feedback?(ggrisco)
You need to log in
before you can comment on or make changes to this bug.
Description
•