863500 - crash in libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister

Status: RESOLVED WORKSFORME

(Core :: Networking: Cache, defect)

Description

[Inder]

This crash was seen during test involving camera, camcorder, music and gallery.
Here is the crash signature:
Crash reason: SIGSEGV
Crash address: 0x8000000b
Thread 0 (crashed)
0 libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister [POfflineCacheUpdateChild.cpp : 112 + 0x4]
r0 = 0x41a87504 r1 = 0x00000001 r2 = 0x4468ea9c r3 = 0x7fffffff
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20af8 lr = 0x406381e7 pc = 0x406381e2
Found by: given as instruction pointer in context
1 libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister [POfflineCacheUpdateChild.cpp : 112 + 0x7]
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b00 pc = 0x406381e7
Found by: call frame info
2 libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister [POfflineCacheUpdateChild.cpp : 112 + 0x7]
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b08 pc = 0x406381e7
Found by: call frame info
3 libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister [POfflineCacheUpdateChild.cpp : 112 + 0x7]
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b10 pc = 0x406381e7
Found by: call frame info
4 libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister [POfflineCacheUpdateChild.cpp : 112 + 0x7]
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b18 pc = 0x406381e7
Found by: call frame info
5 libxul.so!mozilla::docshell::POfflineCacheUpdateParent::DestroySubtree [POfflineCacheUpdateParent.cpp : 397 + 0x5]
r4 = 0x44844940 r5 = 0x00000001 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b20 pc = 0x40b16707
Found by: call frame info
6 libxul.so!mozilla::dom::indexedDB::PIndexedDBRequestChild::OnMessageReceived [PIndexedDBRequestChild.cpp : 194 + 0x7]
r4 = 0x44844940 r5 = 0x00000000 r6 = 0xbee20ebc r7 = 0xbee20b74
r8 = 0x001d0000 r9 = 0xbee20b3c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b30 pc = 0x40b5de17
Found by: call frame info
7 libxul.so!mozilla::dom::PContentChild::OnMessageReceived [PContentChild.cpp : 2325 + 0x7]
r4 = 0x41a311a8 r5 = 0xbee20ebc r6 = 0xbee20ebc r7 = 0x414c473c
r8 = 0xbee20f20 r9 = 0x00000006 r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20b98 pc = 0x40b7bde9
Found by: call frame info
8 libxul.so!mozilla::ipc::AsyncChannel::OnDispatchMessage [AsyncChannel.cpp : 473 + 0x9]
r4 = 0x41a311b0 r5 = 0xbee20ebc r6 = 0xbee20ebc r7 = 0xbee218b8
r8 = 0xbee20f20 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20ea8 pc = 0x40b030e1
Found by: call frame info
9 libxul.so!mozilla::ipc::RPCChannel::OnMaybeDequeueOne [RPCChannel.cpp : 402 + 0x7]
r0 = 0x41a311b0 r1 = 0xbee20ebc r4 = 0x41a311b0 r5 = 0xbee20ebc
r6 = 0xbee20ebc r7 = 0xbee218b8 r8 = 0xbee20f20 r9 = 0x41a06c0c
r10 = 0x00000000 fp = 0x00000000 sp = 0xbee20eb8 pc = 0x40b07f87
Found by: call frame info
10 libxul.so!RunnableMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::*)(), Tuple0>::Run [tuple.h : 383 + 0x5]
r4 = 0xbee218b0 r5 = 0x438401e0 r6 = 0xbee20f28 r7 = 0xbee218b8
r8 = 0xbee20f20 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbee20ef0 pc = 0x40ae991b
Found by: call frame info

Comment 1

[Inder]

Attachment: decoded minidump

Comment 3

[Jason Smith [:jsmith]]

Honza - Any ideas?

This is blocking a 1.1 CS milestone for B2G, so your input would be greatly appreciated here to help get this fixed.

Comment 4

[Honza Bambas (:mayhemer)]

I am not sure I'll have time this week.  I'm in MV on workweek, quite busy.

Comment 5

[Honza Bambas (:mayhemer)]

(In reply to Inder from comment #1)
> Created attachment 739342 [details]
> decoded minidump

There is a completely different signature in the minidump.

Comment 6

[Inder]

Attachment: decoded minidump for the crash

Sorry, by mistake uploaded wrong minidump. Here is the correct one.

Comment 7

[Inder]

Honza, any update here? Test guys ran into this crash again last night during testing on the latest build.

Comment 8

[Wayne Chang [:wchang]]

ni? Honza - have you had any chance to look at this yet?

Comment 9

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

The crash signature looks really weird to me because the call stack contains a mixture of ipdl Parent/Child functions. It might not be decoded from a correct ELF.

Comment 10

[Michael Vines [:m1] [:evilmachines]]

Inder, can you please double check that the minidump decode was good, per comment 9

Comment 11

[Inder]

Attachment: decoded minidump

Generated the stack again from the dump file and using the build which caused it. Doesn't look very different from the previous one.

Comment 12

[Alan Huang]

(In reply to Shih-Chiang Chien [:schien] from comment #9)
> The crash signature looks really weird to me because the call stack contains
> a mixture of ipdl Parent/Child functions. It might not be decoded from a
> correct ELF.

I suggest using non-optimized build to get correct symbols. In many cases, we had incorrect symbols while using optimized build.

"export B2G_NOOPT=1"
in .userconfig or
"ac_add_options --disable-optimize"
in gonk/default-gecko-config

Comment 13

[Honza Bambas (:mayhemer)]

I was suspecting bug 773487 could be related.  However, I'm not able to reproduce it on m-c desktop browser nor on b2g ipc enabled desktop build.

I really don't have cycles right now to try to figure this out according there are just 2 (+1 dup) crash reports of this.

STR or better dump would be good.

Comment 14

[Wayne Chang [:wchang]]

inder, can you do this with the build suggested in comment 12?

Comment 15

[Inder]

(In reply to Wayne Chang [:wchang] from comment #14)
> inder, can you do this with the build suggested in comment 12?
Ok, sure I will try to create a build and ask testers to reproduce the crash on it.
Not sure I fully understand the comment "call stack contains a mixture of ipdl Parent/Child functions". Are you referring to "mozilla::docshell::POfflineCacheUpdateChild::Unregister" appearing 5 times on the callstack?

Comment 16

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Inder from comment #15)
> (In reply to Wayne Chang [:wchang] from comment #14)
> > inder, can you do this with the build suggested in comment 12?
> Ok, sure I will try to create a build and ask testers to reproduce the crash
> on it.
> Not sure I fully understand the comment "call stack contains a mixture of
> ipdl Parent/Child functions". Are you referring to
> "mozilla::docshell::POfflineCacheUpdateChild::Unregister" appearing 5 times
> on the callstack?
No, what I mean is 5 libxul.so!mozilla::docshell::POfflineCacheUpdateParent::DestroySubtree should never call libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister. The instance of these two objects live in two different processes.

Comment 17

[Michael Vines [:m1] [:evilmachines]]

(In reply to Shih-Chiang Chien [:schien] from comment #16)
> No, what I mean is 5
> libxul.so!mozilla::docshell::POfflineCacheUpdateParent::DestroySubtree
> should never call
> libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister. The
> instance of these two objects live in two different processes.

Hmmm...the POfflineCacheUpdateParent.cpp in my tree contains the following:

void
POfflineCacheUpdateParent::DestroySubtree(ActorDestroyReason why)
{
    // Unregister from our manager.
    Unregister(mId);                        <---- line 397
    mId = 1;

    // Finally, destroy "us".
    ActorDestroy(why);
}

Comment 18

[Michael Vines [:m1] [:evilmachines]]

Well comment 17 didn't make too much sense, but I've walked all the frames of the dump and all the line numbers match up.  So I'm doubtful that we have a symbol issue here.  I can't think of a minidump that we've seen in quite a while with bad symbols actually.   What if we assume the symbols are correct for a moment and think if there's a way that this stack trace could occur?

Comment 19

[Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #17)
> (In reply to Shih-Chiang Chien [:schien] from comment #16)
> > No, what I mean is 5
> > libxul.so!mozilla::docshell::POfflineCacheUpdateParent::DestroySubtree
> > should never call
> > libxul.so!mozilla::docshell::POfflineCacheUpdateChild::Unregister. The
> > instance of these two objects live in two different processes.
> 
> Hmmm...the POfflineCacheUpdateParent.cpp in my tree contains the following:
> 
> void
> POfflineCacheUpdateParent::DestroySubtree(ActorDestroyReason why)
> {
>     // Unregister from our manager.
>     Unregister(mId);                        <---- line 397
>     mId = 1;
> 
>     // Finally, destroy "us".
>     ActorDestroy(why);
> }
This one should call POfflineCacheUpdateParent::Unregister(int32_t aId) at line 158.

Comment 20

[Michael Vines [:m1] [:evilmachines]]

(In reply to Shih-Chiang Chien [:schien] from comment #19)
> This one should call POfflineCacheUpdateParent::Unregister(int32_t aId) at
> line 158.

Maybe.  Any classes inherit from POfflineCacheUpdateParent and override Unregister?  I guess my point is that symbols in the frame all line up with valid source lines, and there seem to be some plausible reasons for why such a backtrace could occur, even though it perhaps shouldn't per the design.  We can try to reproduce this crash on a non-optimized build but I bet we'll see the same trace next week when we get the results back, and we'll be back in the same position as we are now.   We've seen this exact crash on multiple builds now.

Comment 21

[Honza Bambas (:mayhemer)]

(In reply to Michael Vines [:m1] [:evilmachines] from comment #20)
> We've seen this exact crash on
> multiple builds now.

Sounds reproducible then.  Have you seen it on a desktop build?  Are there any STR?  Any...

Comment 22

[Michael Vines [:m1] [:evilmachines]]

Reproducable in overnight stabilty automation, yes.  We don't test the desktop.

Inder, can you please provide an example scenario where we've seen this?

Comment 23

[Josh Matthews [:jdm]]

Note that it's entirely possible that POfflineUpdateParent::Unregister is identical to POfflineUpdateChild::Unregister so the symbols could be merged in optimized builds.

Comment 24

[Inder]

These stability crashes haven't happened on a very recent build but appeared on AU80 and AU81 which is about a week old and previously on AU60 build.

There are multiple STRs for this issue. For example,
 1.Open camera and take pictures
 2.Open gallery from camera apps and check the picks and again go to camera apps
 3.Play Music in background in repeat mode
 4.Insert wired headset and Play FM
 5.Open camera and take pictures
 6.Open camcorder and record videos
 7.Repeat the steps multiple times.
 8.After 3 to 4 hours camera apps not working, it is open but we are unable to take pictures
 9.Camera apps is in struck/Freeze state. 
10.Open camera apps multiple times and try to take pictures
 11.After some time device collected mini dumps. 

and,
1.Play Music in background in repeat mode
2.Enable auto answer.
3.Connect the GPS cable and open the GPS application.
4.Receive MT calls Randomly (Short duration).
5.Open multiple applications. (Camera, video, gallery phone, Messaging etc.,
6.Slowly Press Home key and swiping up all the applications(Same as closing the applications)
7.While swiping up the applications, Mini dumps are generated in the phone

and,
1.Play Music in background in repeat mode
2.Enable auto answer.
3.Make MO calls from QXDM continuously (Short duration)
4.Receive MT calls Randomly (Short duration).
5.Performed manual testing for 2 to 3 hrs on different applications,
6.Open multiple applications. (Like Camera, video, gallery phone, Messaging etc.,)
7.Slowly Press Home key and swipe up all the applications(Same as closing the applications)
8.While swiping up the applications, Mini dumps are generated in the phone

There is another crashstack which looks a little different from the one in the description. I will post the crashdump and the stack in a sec.

Comment 25

[Inder]

Attachment: decoded minidump 2

Crash reason: SIGSEGV
Crash address: 0x0
Thread 0 (crashed)
0 0x0
r0 = 0x43782a90 r1 = 0x00000001 r2 = 0x443a4ccc r3 = 0x00000000
r4 = 0x43782a90 r5 = 0x00000001 r6 = 0xbe94deb4 r7 = 0xbe94db6c
r8 = 0x001d0000 r9 = 0xbe94db34 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94db18 lr = 0x40b456ff pc = 0x00000000
Found by: given as instruction pointer in context
1 libxul.so!mozilla::dom::indexedDB::PIndexedDBRequestChild::OnMessageReceived [PIndexedDBRequestChild.cpp : 194 + 0x7]
sp = 0xbe94db28 pc = 0x40b8f2db
Found by: stack scanning
2 libxul.so!mozilla::dom::PContentChild::OnMessageReceived [PContentChild.cpp : 2301 + 0x7]
r4 = 0x41a1b618 r5 = 0xbe94deb4 r6 = 0xbe94deb4 r7 = 0x414fa48c
r8 = 0xbe94df18 r9 = 0x00000006 sp = 0xbe94db90 pc = 0x40bad6b9
Found by: call frame info
3 libxul.so!mozilla::ipc::AsyncChannel::OnDispatchMessage [AsyncChannel.cpp : 471 + 0x5]
r4 = 0x41a1b624 r5 = 0xbe94deb4 r6 = 0xbe94deb4 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94dea0 pc = 0x40b31f0b
Found by: call frame info
4 libxul.so!mozilla::ipc::RPCChannel::OnMaybeDequeueOne [RPCChannel.cpp : 402 + 0x7]
r0 = 0x41a1b624 r1 = 0xbe94deb4 r4 = 0x41a1b624 r5 = 0xbe94deb4
r6 = 0xbe94deb4 r7 = 0xbe94e8b8 r8 = 0xbe94df18 r9 = 0x41a06c0c
r10 = 0x00000000 fp = 0x00000000 sp = 0xbe94deb0 pc = 0x40b36d87
Found by: call frame info
5 libxul.so!RunnableMethod<IPC::ChannelProxy::Context, void (IPC::ChannelProxy::Context::*)(), Tuple0>::Run [tuple.h : 383 + 0x5]
r4 = 0xbe94e8ac r5 = 0x43e8b2a8 r6 = 0xbe94df20 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94dee8 pc = 0x40b186b3
Found by: call frame info
6 libxul.so!mozilla::ipc::RPCChannel::DequeueTask::Run [RPCChannel.h : 425 + 0x9]
r4 = 0xbe94e8ac r5 = 0x43e8b2a8 r6 = 0xbe94df20 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94def0 pc = 0x40b35731
Found by: call frame info
7 libxul.so!MessageLoop::RunTask [message_loop.cc : 337 + 0x5]
r4 = 0xbe94e8ac r5 = 0x43e8b2a8 r6 = 0xbe94df20 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94def8 pc = 0x40c62bfd
Found by: call frame info
8 libxul.so!MessageLoop::DeferOrRunPendingTask [message_loop.cc : 345 + 0x5]
r4 = 0x00000001 r5 = 0xbe94df10 r6 = 0xbe94df20 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94df08 pc = 0x40c63a2f
Found by: call frame info
9 libxul.so!MessageLoop::DoWork [message_loop.cc : 445 + 0x7]
r4 = 0xbe94e8ac r5 = 0xbe94df10 r6 = 0xbe94df20 r7 = 0xbe94e8b8
r8 = 0xbe94df18 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94df10 pc = 0x40c6460d
Found by: call frame info
10 libxul.so!mozilla::ipc::DoWorkRunnable::Run [MessagePump.cpp : 42 + 0x7]
r4 = 0xbe94e8ac r5 = 0x00000001 r6 = 0x00000000 r7 = 0x00000001
r8 = 0xbe94df97 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94df40 pc = 0x40b350ed
Found by: call frame info
11 libxul.so!nsThread::ProcessNextEvent [nsThread.cpp : 620 + 0x5]
r4 = 0x41a06be0 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000001
r8 = 0xbe94df97 r9 = 0x41a06c0c r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94df50 pc = 0x40c40d0f
Found by: call frame info
12 libxul.so!NS_ProcessNextEvent_P [nsThreadUtils.cpp : 237 + 0xb]
r4 = 0x00000000 r5 = 0xbe94e8ac r6 = 0x41a02320 r7 = 0x00000001
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94df90 pc = 0x40c210df
Found by: call frame info
13 libxul.so!mozilla::ipc::MessagePump::Run [MessagePump.cpp : 82 + 0x7]
r0 = 0x41a06be0 r1 = 0x01000000 r4 = 0x41a02310 r5 = 0xbe94e8ac
r6 = 0x41a02320 r7 = 0x00000001 r8 = 0x41a23000 r9 = 0x41a28000
r10 = 0x00000000 fp = 0x00000000 sp = 0xbe94dfa0 pc = 0x40b351fd
Found by: call frame info
14 libxul.so!mozilla::ipc::MessagePumpForChildProcess::Run [MessagePump.cpp : 231 + 0x7]
r4 = 0xbe94e8ac r5 = 0x41a02310 r6 = 0xbe94e8ac r7 = 0x00000001
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94dfc8 pc = 0x40b352af
Found by: call frame info
15 libxul.so!MessageLoop::RunInternal [message_loop.cc : 219 + 0x5]
r4 = 0xbe94e8ac r5 = 0x43751400 r6 = 0x41a06be0 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94dfe0 pc = 0x40c62bb9
Found by: call frame info
16 libxul.so!MessageLoop::Run [message_loop.cc : 212 + 0x5]
r4 = 0xbe94e8ac r5 = 0x43751400 r6 = 0x41a06be0 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94dfe8 pc = 0x40c62c63
Found by: call frame info
17 libxul.so!nsBaseAppShell::Run [nsBaseAppShell.cpp : 163 + 0x7]
r0 = 0x00000002 r1 = 0x4150a700 r2 = 0xbe94e8ac r3 = 0xbe94e048
r4 = 0x00000000 r5 = 0x43751400 r6 = 0x41a06be0 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e000 pc = 0x40abb495
Found by: call frame info
18 libxul.so!XRE_RunAppShell [nsEmbedFunctions.cpp : 646 + 0x5]
r4 = 0xbe94e014 r5 = 0x41a02310 r6 = 0x00000002 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e010 pc = 0x4044f71d
Found by: call frame info
19 libxul.so!mozilla::ipc::MessagePumpForChildProcess::Run [MessagePump.cpp : 198 + 0x3]
r0 = 0x41a02310 r1 = 0x43751400 r2 = 0x4377b600 r4 = 0xbe94e8ac
r5 = 0x41a02310 r6 = 0x00000002 r7 = 0x00000003 r8 = 0x41a23000
r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000 sp = 0xbe94e028
pc = 0x40b3527d
Found by: call frame info
20 libxul.so!MessageLoop::RunInternal [message_loop.cc : 219 + 0x5]
r4 = 0xbe94e8ac r5 = 0x41a1b600 r6 = 0x00000002 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e040 pc = 0x40c62bb9
Found by: call frame info
21 libxul.so!MessageLoop::Run [message_loop.cc : 212 + 0x5]
r4 = 0xbe94e8ac r5 = 0x41a1b600 r6 = 0x00000002 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e048 pc = 0x40c62c63
Found by: call frame info
22 libxul.so!XRE_InitChildProcess [nsEmbedFunctions.cpp : 485 + 0xb]
r0 = 0x00000001 r1 = 0x00000000 r2 = 0xbe94e8ac r3 = 0x00000000
r4 = 0xbe94e8ac r5 = 0x41a1b600 r6 = 0x00000002 r7 = 0x00000003
r8 = 0x41a23000 r9 = 0x41a28000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e060 pc = 0x4044fac1
Found by: call frame info
23 plugin-container!main [MozillaRuntimeMain.cpp : 60 + 0x5]
r4 = 0xbe94ea14 r5 = 0x00000005 r6 = 0xbe94e9e4 r7 = 0xbe94ea30
r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94e9e0 pc = 0x00008533
Found by: call frame info
24 libc.so!__libc_init [libc_init_dynamic.c : 114 + 0x7]
r0 = 0x00000006 r1 = 0x41a06b80 r4 = 0x000084d4 r5 = 0xbe94ea14
r6 = 0x00000006 r7 = 0xbe94ea30 r8 = 0x00000000 r9 = 0x00000000
r10 = 0x00000000 fp = 0x00000000 sp = 0xbe94e9f8 pc = 0x40108a77
Found by: call frame info
25 0xb00045a9
r4 = 0x00000000 r5 = 0x00000000 r6 = 0x00000000 r7 = 0x00000000
r8 = 0x00000000 r9 = 0x00000000 r10 = 0x00000000 fp = 0x00000000
sp = 0xbe94ea10 pc = 0xb00045ab
Found by: call frame info

Comment 27

[Alan Huang]

I tried to hack debugger.c to know which class inherit IndexedDBRequestChildBase actually crashed. 

I used latest 5/15 build, followed reproducing step in comment 24. But I cannot reproduce this bug.

Comment 28

[Alan Huang]

(In reply to Inder from comment #24)
> These stability crashes haven't happened on a very recent build but appeared
> on AU80 and AU81 which is about a week old and previously on AU60 build.

Do we still find minidump in latest build? I didn't find this in 5/15 build, which should be AU94 by the name, I think.

Comment 29

[Kai-Chih Hu [:khu]]

Alan, is it something you can help? Thanks!

Comment 30

[Inder]

We haven't seen this crash in the recent builds. Closing it for now. Will reopen if it resurfaces.

Comment 31

[Scoobidiver (away)]

(In reply to Inder from comment #30)
> We haven't seen this crash in the recent builds. 
B2G 18.0/20130518 is recent for me. See bp-60189f8c-168f-48a1-a30e-db9a12130520.

Comment 32

[Inder]

(In reply to Scoobidiver from comment #31)
> B2G 18.0/20130518 is recent for me. See
> bp-60189f8c-168f-48a1-a30e-db9a12130520.
Ah, ok. I was just referring to our stability testing. Please feel free to reopen the bug.