805754 - crash in mozilla::Logger::~Logger with abort message: "file ../../../ipc/chromium/src/base/thread_local_posix.cc, line 33"

Status: RESOLVED INCOMPLETE

(Core :: IPC, defect, P5)

Description

[Scoobidiver (away)]

It's #7 top crasher in 17.0b3. Assuming it's a regression between Beta 2 and Beta 3 (it might have been there previously with other mozalloc_abort signatures), the regression range is: 
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=437727b79031&tochange=8a0d96bfd52b

Signature 	mozalloc_abort | arena_avail_tree_insert More Reports Search
UUID	5a96b1d8-26eb-40cb-9103-750332121026
Date Processed	2012-10-26 08:15:39
Uptime	1
Last Crash	21.6 minutes before submission
Install Age	2.2 hours since version was first installed.
Install Time	2012-10-26 06:03:26
Product	FennecAndroid
Version	17.0
Build ID	20121023123711
Release Channel	beta
OS	Linux
OS Version	0.0.0 Linux 3.1.10-1009029 #1 SMP PREEMPT Tue Sep 4 21:58:53 KST 2012 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
xpcom_runtime_abort(###!!! ABORT: file /builds/slave/rel-m-beta-andrd-bld/build/ipc/chromium/src/base/thread_local_posix.cc, line 33)
samsung GT-P7500
samsung/GT-P7500/GT-P7500:4.0.4/IMM76D/BULP5:user/release-keys
Processor Notes 	WARNING: JSON file missing Add-ons
EMCheckCompatibility	False	
Device	samsung GT-P7500
Android API Version	15 (REL)
Android CPU ABI	armeabi-v7a

Frame 	Module 	Signature 	Source
0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:19
1 	libc.so 	libc.so@0x1225e 	
2 	libmozglue.so 	arena_avail_tree_insert 	memory/mozjemalloc/jemalloc.c:3146
3 		@0x622d6d2b 	
4 	libmozglue.so 	malloc_mutex_unlock 	memory/mozjemalloc/jemalloc.c:1627
5 	libmozglue.so 	arena_malloc 	memory/mozjemalloc/jemalloc.c:4127
6 	libmozglue.so 	arena_malloc 	memory/mozjemalloc/jemalloc.c:4127
7 	libmozglue.so 	imalloc 	memory/mozjemalloc/jemalloc.c:4207
8 	libmozglue.so 	__wrap_malloc 	memory/mozjemalloc/jemalloc.c:6291
9 	libmozalloc.so 	moz_malloc 	memory/mozalloc/mozalloc.cpp:64
10 	libxul.so 	nsStringBuffer::Alloc 	xpcom/string/src/nsSubstring.cpp:177
11 	libxul.so 	nsACString_internal::MutatePrep 	xpcom/string/src/nsTSubstring.cpp:130
12 	libxul.so 	nsACString_internal::ReplacePrepInternal 	xpcom/string/src/nsTSubstring.cpp:189
13 		@0x5c954696 	
14 	libxul.so 	nsACString_internal::Assign 	nsCharTraits.h:471
15 		@0x21 	
16 	libxul.so 	nsACString_internal::SetCapacity 	xpcom/string/src/nsTSubstring.cpp:532
17 	libxul.so 	nsACString_internal::SetLength 	xpcom/string/src/nsTSubstring.cpp:582

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort+|+arena_avail_tree_insert
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Let's get some URLs and take it from there, no need to nom tracking ESR17 since that won't be an issue until we're dealing with FF18.

Comment 2

[Scoobidiver (away)]

(In reply to Lukas Blakk [:lsblakk] from comment #1)
> no need to nom tracking ESR17
Sorry, wrong flag.

Comment 3

[Marcia Knous [:marcia]]

No URLs for the first signature, here are the ones for the second signature:

56 	about:home
22 	about:blank
5 	http://www.google.com/
3 	http://www.google.com/m?hl=en&source=android-launcher-widget&q=naruto+wiki
2 	https://mobile.twitter.com/
1 	http://m.facebook.com/home.php?refid=28&m_sess=soBIrV64-rVeFIGrP&ref=pymk
1 	https://www.hsbcbillpay.com/
1 	http://prisongames.mobi/Prison.apk
1 	https://rwscott.no-ip.org/keygen.html
1 	http://www.google.com/m?hl=ja&gl=jp&client=ms-android-sonyericsson&source=androi
1 	https://addons.mozilla.org/en-US/android/addon/flash-video-downloader-youtube/?s
1 	wyciwyg://94164/http://mediadecoder.blogs.nytimes.com/2012/10/22/young-people-fr
1 	https://certificados.unison.mx/certsrv/certcarc.asp
1 	http://www.google.com.sa/search?hl=ar&redir_esc=&client=ms-android-samsung&sourc
1 	http://www.slaati.com/inf/
1 	http://www.google.com/m?hl=en&source=android-launcher-widget&q=justice+league
1 	http://www.tagged.com/apps/pets.html?ll=nav#/pet/5422281556
1 	http://www.google.com.sa/search?hl=ar&redir_esc=&client=ms-android-samsung&sourc
1 	http://saintsrow.wikia.com/wiki/Saints_Row:_The_Third
1 	https://m.facebook.com/sharer.php?u=http%251%243A%252%242F%253%242Fwww.viber.com
1 	http://m.youtube.com/home
1 	https://accounts.google.com/ServiceLoginAuth
1 	http://m.gsmarena.com/
1 	http://www.buzzfeed.com/daves4/people-you-wish-you-knew-in-real-life?s=mobile
1 	about:addons
1 	http://www.google.com/m?q=5giay.vn&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:
1 	http://www.google.com.sa/search?hl=ar&redir_esc=&client=ms-android-samsung&sourc
1 	file:///mnt/sdcard/com.blackcrystal.and.ExtremeSex4storage/path1/g1_1.txt
1 	http://www.google.com.ly/search?hl=ar&redir_esc=&client=ms-android-samsung&sourc
1 	http://messagerie-12.sfr.fr/webmail/
1 	http://www.google.tn/search?hl=ar&redir_esc=&client=ms-android-samsung&source=an
1 	http://www.google.com/m?q=goo&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:offic
1 	http://www.google.co.th/search?hl=th&redir_esc=&client=ms-android-sonyericsson&s
1 	wyciwyg://25716/http://www.nytimes.com/
1 	http://www.beyondtherack.com/event/calendar?utm_source=daily&utm_medium=email&ut
1 	http://chibepazam.ir/

Comment 4

[Scoobidiver (away)]

(In reply to Marcia Knous [:marcia] from comment #3)
> here are the ones for the second signature:
Unfortunately, the second one is a compilation of crashes on abort, so not specific to this bug.

Comment 5

[JP Rosevear [:jpr]]

Seems all ARM

Comment 6

[Mike Hommey [:glandium]]

Interestingly, the stack doesn't quite fit the abort message...

Comment 7

[Scoobidiver (away)]

It still happens in the latest trunk (bp-5cec39fb-1099-43d4-8b50-c8e452121031) and in 18.0a2 but seems to be a lower volume crash.

Comment 8

[Alex Keybl [:akeybl]]

If this is a b3 regression, these would be the bugs potentially involved in the regression: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=627234%2C803583%2C802557%2C801305%2C802557%2C793969%2C795281%2C802946%2C802946%2C802946%2C802616%2C771832%2C793253%2C791601%2C789960%2C765409%2C787658%2C786791%2C786886%2C802355%2C792405%2C801957%2C795226%2C802396%2C797036%2C797036%2C793276%2C789046%2C758200%2C774304%2C796039%2C774618%2C795165%2C793848%2C798677%2C792106%2C792106%2C800840%2C801874%2C803385%2C798678%2C798678%2C802697%2C803181%2C792280%2C791344%2C802929%2C766817%2C785050%2C794640%2C802436%2C800817%2C799299%2C800386%2C800386%2C789075%2C795745%2C791174%2C784360%2C802653%2C798974%2C792324%2C;list_id=4835593

None of the patches are FF17-specific (although perhaps a backport was different for one of these). /me wonders if this will be a top crash in beta 4 as well.

bsmedberg - anything jump out at you in that list from the IPC angle?
kbrosnan - can you try reproducing given comment 3? Looks like the Galaxy S is affected.

Comment 9

[V. Korn]

I usually get exactly similar crash reports after FennecAndroid 17.0 hung on Android, closed by system with hung report sent to Google and Firefox started again - after new start it instantly crash and producing such crash report.
In example 88374315-cda4-4c9e-8897-878362121031

Comment 10

[Scoobidiver (away)]

(In reply to Alex Keybl [:akeybl] from comment #8)
> None of the patches are FF17-specific (although perhaps a backport was
> different for one of these). /me wonders if this will be a top crash in beta
> 4 as well.
A difference in ranking between Beta and Aurora/Nightly might be caused by the difference in the representativity of populations (75,000 vs 3,000/1,000).
It's likely caused by a patch not specific to 17.0.

Comment 11

[Benjamin Smedberg]

The stack is bogus. The abort message indicates that this line is failing: http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/thread_local_posix.cc#33

So basically pthread_setspecific is returning an error value. We don't have a way to recover from that so we bail.

Without a good stack here it's really hard to say what's going on: this could either be some kind of low-resource situation in pthreads, or a use-after-free situation in gecko (or maybe use-before-allocate?). Ted do you know if there's a way to get better stacks from these?

Comment 12

[(not currently active) Ted Mielczarek]

The only way to get better stacks here is probably to have symbols for libc and whatever else is between abort and the gecko code.

Comment 13

[Benjamin Smedberg]

Ted, can we do that for particular systems? e.g. the ones from V.Korn above and reprocess those crashes?

Comment 14

[(not currently active) Ted Mielczarek]

The simplest way would probably be to have them "adb pull" the system libraries in question and mail them to one of us, then we can run dump_syms on them and put them on the symbol server.

Comment 15

[Benjamin Smedberg]

V. Korn, is that something you could do? You'll need an android SDK in order to do that (adb is part of the SDK).

Comment 16

[V. Korn]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #14)
> The simplest way would probably be to have them "adb pull" the system
> libraries in question and mail them to one of us, then we can run dump_syms
> on them and put them on the symbol server.

No problem, tell me that exactly i need to pull and i will do it.

Comment 17

[(not currently active) Ted Mielczarek]

Replied via email.

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

We're past the deadline of being able to accept speculative fixes on beta so this will have to go unfixed in 17. Will track for 18 in the hopes that we are moving toward a possible fix here.

Comment 19

[(not currently active) Ted Mielczarek]

Okay, I lost track of this for a bit, but I uploaded the symbols from V. Korn's libc to the symbol server. We should be able to reprocess his crashes and get a more useful stack.

Comment 20

[(not currently active) Ted Mielczarek]

(In reply to V. Korn from comment #9)
> I usually get exactly similar crash reports after FennecAndroid 17.0 hung on
> Android, closed by system with hung report sent to Google and Firefox
> started again - after new start it instantly crash and producing such crash
> report.
> In example 88374315-cda4-4c9e-8897-878362121031

I processed this crash locally. The stack still isn't great, but:
Thread 14 (crashed)
 0  libmozalloc.so!mozalloc_abort [mozalloc_abort.cpp:7e4c2abb9fc9 : 19 + 0x4]
     r4 = 0x4010e6f8    r5 = 0x698999ac    r6 = 0x00000000    r7 = 0xffffffff
     r8 = 0x6e27193d    r9 = 0x00000001   r10 = 0x698995c0    fp = 0x00000000
     sp = 0x698995b0    lr = 0x400e5f23    pc = 0x6713b704
    Found by: given as instruction pointer in context
 1  libc.so!putc + 0x28
     r4 = 0x4010e6f8    r5 = 0x698999ac    r6 = 0x00000000    r7 = 0xffffffff
     r8 = 0x6e27193d    r9 = 0x00000001   r10 = 0x698995c0    fp = 0x00000000
     sp = 0x698995b0    pc = 0x400e5f23
    Found by: call frame info
 2  libxul.so + 0x116704e
     r4 = 0xffffffff    r5 = 0x66cd8ab7    r6 = 0x00000000    r7 = 0xffffffff
     r8 = 0x6e27193d    r9 = 0x00000001   r10 = 0x698995c0    fp = 0x00000000
     sp = 0x698995c0    lr = 0x6e8e5050    pc = 0x6e8e5050
    Found by: call frame info

< frames 3 - 10 are all garbage found by stack scanning >

11  libxul.so!JSC::Yarr::Parser<JSC::Yarr::YarrPatternConstructor>::CharacterClassParserDelegate::atomBuiltInCharacterClass [YarrPattern.h:8a0d96bfd52b : 398 + 0x8]
     sp = 0x6989962c    pc = 0x6e696c20
    Found by: stack scanning
12  0x6b100bf6
     r4 = 0x33332065    r5 = 0x6c1a2200    r6 = 0x66cd919b    r7 = 0x6c1a22c8
     r8 = 0x66cdb117    sp = 0x69899644    pc = 0x6b100bf8
    Found by: call frame info
13  libmozglue.so!malloc_mutex_unlock [jemalloc.c:8a0d96bfd52b : 1627 + 0x3]
     sp = 0x69899668    pc = 0x66cd919b
    Found by: stack scanning
14  libmozglue.so!arena_malloc [jemalloc.c:8a0d96bfd52b : 4127 + 0x3]
     r4 = 0x6c1a21f0    sp = 0x69899670    pc = 0x66cdb117
    Found by: call frame info
15  libmozglue.so!imalloc [jemalloc.c:8a0d96bfd52b : 4207 + 0xb]
     r4 = 0x0000002c    r5 = 0x00000023    r6 = 0x698996dc    r7 = 0x698996d8
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996a0    pc = 0x66cdb257
    Found by: call frame info
16  libmozglue.so!__wrap_malloc [jemalloc.c:8a0d96bfd52b : 6291 + 0x5]
     r4 = 0x0000002c    r5 = 0x00000023    r6 = 0x698996dc    r7 = 0x698996d8
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996a8    pc = 0x66cdb277
    Found by: call frame info
17  libmozalloc.so!moz_malloc [mozalloc.cpp:7e4c2abb9fc9 : 64 + 0x3]
     r4 = 0x00000024    r5 = 0x00000023    r6 = 0x698996dc    r7 = 0x698996d8
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996b0    pc = 0x6713b6b7
    Found by: call frame info
18  libxul.so!nsStringBuffer::Alloc [nsSubstring.cpp:8a0d96bfd52b : 177 + 0x7]
     r4 = 0x00000024    r5 = 0x00000023    r6 = 0x698996dc    r7 = 0x698996d8
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996b8    pc = 0x6e27ca09
    Found by: call frame info
19  libxul.so!nsACString_internal::MutatePrep [nsTSubstring.cpp:8a0d96bfd52b : 1
30 + 0x5]
     r4 = 0x6c354698    r5 = 0x00000023    r6 = 0x698996dc    r7 = 0x698996d8
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996c0    pc = 0x6e27cc95
    Found by: call frame info
20  libxul.so!nsACString_internal::ReplacePrepInternal [nsTSubstring.cpp:8a0d96bfd52b : 189 + 0x7]
     r4 = 0x6c354698    r5 = 0x00000000    r6 = 0x00000023    r7 = 0x00000000
     r8 = 0x6c354698    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996d8    pc = 0x6e27cf67
    Found by: call frame info
21  libxul.so!nsACString_internal::ReplacePrep [nsTSubstring.h : 719 + 0xf]
     r4 = 0x6c354698    r5 = 0x00000000    r6 = 0x00000023    r7 = 0x00000000
     r8 = 0x00000023    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x698996f8    pc = 0x6e27cfe7
    Found by: call frame info
22  0x6c35419e
     r4 = 0x00000023    r5 = 0x6c354698    r6 = 0x00000000    r7 = 0x6989998c
     r8 = 0x6c3541a0    r9 = 0x6c3542c0   r10 = 0x6c3541a0    fp = 0x6c3541a0
     sp = 0x69899718    pc = 0x6c3541a0
    Found by: call frame info
23  libxul.so!nsACString_internal::SetCapacity [nsTSubstring.cpp:8a0d96bfd52b : 
553 + 0x7]
     sp = 0x69899730    pc = 0x6e27cd97
    Found by: stack scanning
24  libxul.so!nsACString_internal::SetCapacity [nsTSubstring.cpp:8a0d96bfd52b : 532 + 0x5]
     r4 = 0x6c354698    r5 = 0x00000023    r6 = 0x698997d8    sp = 0x69899748
     pc = 0x6e27cee9
    Found by: call frame info
25  libxul.so!nsACString_internal::SetLength [nsTSubstring.cpp:8a0d96bfd52b : 582 + 0x3]
     r4 = 0x6c354698    r5 = 0x00000023    r6 = 0x698997d8    sp = 0x69899760
     pc = 0x6e27cf17
    Found by: call frame info

Thread 0
 0  libc.so!memcpy + 0x87
     r4 = 0x67292de0    r5 = 0x00000001    r6 = 0x67295790    r7 = 0x00000000
     r8 = 0x672928c8    r9 = 0x00000400   r10 = 0x67295278    fp = 0x00000012
     sp = 0xbed42b48    lr = 0x6808e664    pc = 0x400d6798
    Found by: given as instruction pointer in context

<disappointingly, there are no more frames in thread 0>

Comment 21

[(not currently active) Ted Mielczarek]

And here's what dumplookup thinks about the crashing thread's stack:
http://pastebin.mozilla.org/1944501

Comment 22

[Benjamin Smedberg]

This is really weird, to say the least. The stack 

I think the XRE_mainStartup frame is trustworthy, so we're at http://hg.mozilla.org/releases/mozilla-release/annotate/8a0d96bfd52b/toolkit/xre/nsAppRunner.cpp#l3546 and we're probably either freeing a COMPtr or a string in the function scope.

That accounts for either nsACString_internal::Finalize or nsLocalFile::Release being on the stack. But it doesn't explain anything deeper in the stack (since those functions only call ::ReleaseData and other string destructors). And it certainly doesn't explain how "xpcom_runtime_abort(###!!! ABORT: file /builds/slave/rel-m-beta-andrd-bld/build/ipc/chromium/src/base/thread_local_posix.cc, line 33)" appears in the report. Did some other previous thread crash but not actually crash?

Comment 23

[Alex Keybl [:akeybl]]

What are the next steps here? Is there anything that needs to be done in-product to make this crash actionable?

Comment 24

[Robert Kaiser]

It looks like this is in 17.0 but not in 18.0b2, I think we probably can untrack this for 18.

Comment 25

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) from comment #24)
> It looks like this is in 17.0 but not in 18.0b2, I think we probably can
> untrack this for 18.
It's still in 18.0b2 under the mozalloc_abort crash signature but indeed not at a high volume: bp-6b5e1992-8773-4fc3-ab55-c01912121205.

Comment 26

[Scoobidiver (away)]

It's #7 top crasher in the first hours of 18.0. Indeed, almost all mozalloc_abort reports have that abort message.

Comment 27

[Scoobidiver (away)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> Without a good stack here it's really hard to say what's going on
I think it's a good one: bp-afcf1948-d7f1-4b21-8c33-e104a2130111.

Comment 28

[Benjamin Smedberg]

Interesting. This is right at startup, we're at:

http://hg.mozilla.org/mozilla-central/annotate/44dcffe8792b/ipc/chromium/src/base/message_loop.cc#l99

Which initializes http://hg.mozilla.org/mozilla-central/annotate/44dcffe8792b/ipc/chromium/src/base/message_loop.cc#l41

Which ends up where we thought: http://hg.mozilla.org/mozilla-central/annotate/9e15a0d3dff1/ipc/chromium/src/base/thread_local_posix.cc#l32 and pthread_setspecific fails.

I would expect `error` to be in a register, but I'm not sure whether it's preserved through the function call or whether we can retrieve it from the minidump.

Does this correlate with specific devices or maybe custom kernels or something like that?

Comment 29

[Scoobidiver (away)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #28)
> Does this correlate with specific devices or maybe custom kernels or
> something like that?
It occurs from GB to JB.
Here are correlations per device in 18.0 for the last day:
samsung GT-I9100 	10
samsung GT-P3113 	4
samsung GT-P3100 	3
HTC One X 	3
motorola MB865 	2
samsung GT-N7000 	2
HTC Desire C 	2
motorola DROID BIONIC 	2
HTC Sensation 4G 	2
HTC One S 	2
HTC EVO 3D X515m 	2
samsung GT-N8010 	2
samsung GT-P5113 	2
samsung GT-P5100 	2
samsung GT-P5110 	2
samsung SHW-M250K 	1
asus Transformer TF101 	1
samsung SGH-I777 	1
asus Slider SL101 	1
samsung SHV-E160L 	1
Sony SO-05D 	1
Sony Ericsson LT28i 	1
Sony Ericsson ST25i 	1
Sony MT27i 	1
kyocera C5170 	1
ZOPO ZP500+ 	1
samsung SC-02C 	1
MSI MSI_Enjoy_10_Plus 	1
samsung GT-N8013 	1
samsung GT-P3110 	1
samsung GT-P7320T 	1
samsung Galaxy Nexus 	1
samsung SGH-I717D 	1
motorola DROID RAZR 	1
motorola DROID4 	1
samsung SGH-I727R 	1
HTC Velocity 4G 	1
HTC Sensation XE with Beats Audio Z715a 	1
HTC One V 	1
HTC Sensation XE with Beats Audio Z715e 	1
Hisense E860 	1
HTCEVOV4G 	1
HTC ISW12HT 	1
HTC EVO 	1
Acer A500 	1
HTC ADR6410LVW 	1
LGE LG-E612f 	1

Comment 30

[Alex Keybl [:akeybl]]

It's very unlikely that we'll find a low risk fix for this longstanding issue in time for an 18.0.1. We should continue investigating in the FF19 timeframe, but we may permanently untrack if we can't figure out how to make this bug actionable.

Comment 31

[Scoobidiver (away)]

Now that stack traces for abort crashes are clean, it's #24 top crasher in 20.0a2 and #41 in 21.0a1, so no longer a top crasher.

Comment 32

[Kevin Brosnan [Ex-Mozilla]]

Attachment: ANR traces.txt

I hit this after getting a couple ANRs browsing around the addons.m.o themes site on Firefox for Android I was aggressively switching between light weight themes. Attached is the /data/anr/traces.txt 

I was using a HTC G2 running Cyanogenmod 7.2 (Android 2.3.7)

bp-15737da6-bca2-4562-b0ca-3a1662130131

Comment 33

[Scoobidiver (away)]

Bug 840294 with the same crash signature and a similar abort message has a fix.

Comment 34

[Benjamin Smedberg]

That unfortunately doesn't look related at all. You need to look at the frame "above" base::MessagePumpLibevent::WatchFileDescriptor to see which runtime check was being triggered for this abort.

Comment 35

[Scoobidiver (away)]

It happens also on Linux: bp-8fd8dca6-7a85-46ff-b118-dbf092130215.

Comment 37

[Scoobidiver (away)]

At last a non buggy stack trace because of bug 884300:
Frame 	Module 	Signature 	Source
0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:30
1 	libxul.so 	NS_DebugBreak 	xpcom/base/nsDebugImpl.cpp:430
2 	libxul.so 	mozilla::Logger::~Logger 	ipc/chromium/src/base/logging.cc:47
3 	libxul.so 	base::ThreadLocalPlatform::SetValueInSlot 	ipc/chromium/src/base/logging.h:59
4 	libxul.so 	MessageLoop::MessageLoop 	ipc/chromium/src/base/thread_local.h:89
5 	libxul.so 	NS_InitXPCOM2 	ipc/chromium/src/base/message_loop.h:438
6 	libxul.so 	ScopedXPCOMStartup::Initialize 	toolkit/xre/nsAppRunner.cpp:1190
7 	libxul.so 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3920
8 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:4126

Reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*%29+|+NS_DebugBreak+|+mozilla%3A%3ALogger%3A%3A~Logger%28%29

Comment 38

[u421692]

I can reproduce this everytime I perform the steps from https://bugzilla.mozilla.org/show_bug.cgi?id=901426#c0

Comment 39

[Scoobidiver (away)]

It's #1 top crasher in Fennec 26.0a1 likely because of bug 901426.

Comment 40

[Alex Keybl [:akeybl]]

During triage, Kevin volunteered to check if these combined signatures remained a topcrash.

Comment 41

[Kevin Brosnan [Ex-Mozilla]]

Even the signatures with the most crashes on release don't qualify as a top crash. Rank is in the 30-40 range.

Comment 42

[sarsenyev]

This bug was filed from the Socorro interface and is 
report bp-97b1657e-4ed0-41d4-8850-5f7d92131213.
=============================================================

I was able to reproduce this crash 3 times after launching RTSP link on the latest 1.3 Aurora build

Device: Buri 1.3 Aurora Moz RIL
BuildID: 20131213004002
Gaia: 888f9df5515a47d2f5806efee77485e05e1e5416
Gecko: dfae9c83bfbc
Version: 28.0a2
Firmware Version: v1.2_20131115

Comment 43

[Aaron Train [:aaronmt]]

100% reproducible on Nightly (02/18) with native APK web apps on launch on my Samsung Galaxy Note II (Android 4.2)

Comment 44

[Benjamin Smedberg]

aaronmt do you have crash IDs? Since Android doesn't use the IPC layer I wouldn't expect this bug (Logger::~Logger) to be present at all.

Comment 45

[Aaron Train [:aaronmt]]

https://crash-stats.mozilla.com/report/index/68da2426-221c-4b20-bea9-9d29e2140218
https://crash-stats.mozilla.com/report/index/362edf08-31f5-4b69-9aec-39b342140218
https://crash-stats.mozilla.com/report/index/9a8123df-65ef-40e8-9463-7f1282140218
https://crash-stats.mozilla.com/report/index/d5ea22d0-1d7c-4227-a5d8-1960d2140218
https://crash-stats.mozilla.com/report/index/1fad0fc9-34ff-4118-8d82-8c92d2140218
https://crash-stats.mozilla.com/report/index/b4ecfecc-3694-404f-b291-d49042140218

Comment 46

[Aaron Train [:aaronmt]]

See also bug 901426 where this was an issue once before.

Comment 47

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]