Closed Bug 629285 Opened 10 years ago Closed 10 years ago

Firefox 4.0b10 Crash [@ AsyncGetBookmarksForURI<void (nsNavBookmarks::*)(mozilla::places::ItemChangeData), mozilla::places::ItemChangeData>::HandleResult ][@ mozilla::places::ItemChangeData::ItemChangeData(mozilla::places::ItemChangeData const&)]

Categories

(Toolkit :: Places, defect)

x86
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- final+

People

(Reporter: marcia, Assigned: mak)

References

Details

(Keywords: crash, regression, Whiteboard: [softblocker][fixed by bug 637957])

Crash Data

Attachments

(1 file)

Seen while reviewing crash stats. New Mac only crash which is so far low volume. http://tinyurl.com/4dn7uy2 to the reports.

Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	AsyncGetBookmarksForURI<void ,mozilla::places::ItemChangeData>::HandleResult 	toolkit/components/places/src/nsNavBookmarks.cpp:148
1 	XUL 	mozilla::storage::::CallbackResultNotifier::Run 	storage/src/mozStorageAsyncStatementExecution.cpp:100
2 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
3 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:208
4 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3072
5 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1593
6 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
7 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
8 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2182
9 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
10 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
11 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
12 	XUL 	JS_CallFunctionValue 	js/src/jsinterp.h:961
13 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
14 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
15 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
16 	XUL 	XUL@0xe1b69a 	
17 	XUL 	nsHttpChannel::OnDataAvailable 	netwerk/protocol/http/nsHttpChannel.cpp:4109
18 	XUL 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:510
19 	XUL 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:400
20 	XUL 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:112
21 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
22 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:208
23 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3072
24 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1593
25 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
26 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
27 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2182
28 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
29 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
30 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
31 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
32 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
33 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
34 	XUL 	JS_CallFunctionValue 	js/src/jsinterp.h:961
35 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
36 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
37 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
38 	XUL 	XUL@0xe1b69a 	
39 	XUL 	nsNavHistory::RunInBatchMode 	toolkit/components/places/src/nsNavHistory.cpp:4043
40 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:208
41 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3072
42 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1593
43 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
44 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
45 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2182
46 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
47 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
48 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
49 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
50 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
51 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
52 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
53 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
54 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
55 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
56 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
57 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2182
58 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
59 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
60 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
61 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
62 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
63 	XUL 	js_fun_call 	js/src/jsfun.cpp:2115
64 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:692
65 	XUL 	js::Invoke 	js/src/jsinterp.cpp:657
66 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
67 	XUL 	JS_CallFunctionValue 	js/src/jsinterp.h:961
68 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1700
69 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
70 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
71 	XUL 	XUL@0xe1b69a 	
72 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
73 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
74 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
75 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:200
76 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:135
77 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:405
78 	CoreFoundation 	CoreFoundation@0x4e400 	
79 	CoreFoundation 	CoreFoundation@0x4c5f8
taking for investigation
Assignee: nobody → mak77
Blocks: 615992
Keywords: regression
Blocks: 560198
Duplicate of this bug: 629636
See https://bugzilla.mozilla.org/show_bug.cgi?id=629636#c0 for an interesting stack too.
(In reply to comment #3)
> See https://bugzilla.mozilla.org/show_bug.cgi?id=629636#c0 for an interesting
> stack too.
Huh, that seems to implicate Sync here...
OS: Mac OS X → All
(In reply to comment #4)
> (In reply to comment #3)
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=629636#c0 for an interesting
> > stack too.
> Huh, that seems to implicate Sync here...

I think it's unrelated, it's just a visit addition that ends up calling this code (due to the onVisit observer).
OS: All → Mac OS X
due to the above (this crash being cross-platform and a regression) I think I'm going to ask for soft-blocking on it.
blocking2.0: --- → ?
Summary: Firefox 4.0b10 Crash [@ AsyncGetBookmarksForURI<void (nsNavBookmarks::*)(mozilla::places::ItemChangeData), mozilla::places::ItemChangeData>::HandleResult ] → Firefox 4.0b10 Crash [@ AsyncGetBookmarksForURI<void (nsNavBookmarks::*)(mozilla::places::ItemChangeData), mozilla::places::ItemChangeData>::HandleResult ][@ mozilla::places::ItemChangeData::ItemChangeData(mozilla::places::ItemChangeData const&)]
blocking2.0: ? → final+
Whiteboard: [softblocker]
It is #12 top crasher on Mac OS X in 4.0b10 over the last week.
I can reproduce this by deleting a history item. I open Show All History, double click on Today and then delete the entry for Slashdot that I have in there. (The actual URL is probably not relevant)

Other items delete fine. It just just this one.
thanks, will try to reproduce that way.
(In reply to comment #9)
> I can reproduce this by deleting a history item. I open Show All History,
> double click on Today and then delete the entry for Slashdot that I have in
> there. (The actual URL is probably not relevant)
> 
> Other items delete fine. It just just this one.

Are you able to crash every time you do that operation, or only sometimes? I really can't find a way to crash :(
If you can reproduce reliably, maybe I could give you a trybuild to test.
another interesting and related stack: https://crash-stats.mozilla.com/report/index/89fea315-eeea-41c7-8c81-09d2d2110127
the URIBinder crashes trying to dereference the uri.
> Are you able to crash every time you do that operation, or only sometimes? I
> really can't find a way to crash :(
> If you can reproduce reliably, maybe I could give you a trybuild to test.

Yeah this is still totally reproducable for me. I've made backup of my profile directory to be sure. I'm more than happy to play with trybuilds if that gives us more info.
yes please, preserve your environment, I will link here a trybuild and you can test it.
Could you also try to create a new profile, copy your places.sqlite file from the saved profile to that one, and try to crash with the new profile? I'd be interested in knowing if effectively contents of that entry do matter (in such a case I'd love to get a copy of that database by mail, if it's fine for you).
This is the first attempt, can't be 100% sure this will fix the crash, but it's a start and we want these changes regardless.
- avoid passing the struct by value where not needed
- don't pass out the object in the constructor to avoid possible bad addref/release that could delete the object

To check for it to be fixed I'll make a trybuild for Stefan, then I'll keep checking crash-stats.
Attachment #509858 - Flags: review?(sdwilsh)
Comment on attachment 509858 [details] [diff] [review]
patch v1.0 (checked-in)

r=sdwilsh
Attachment #509858 - Flags: review?(sdwilsh) → review+
Stefan, could you try this build please (the macosx64 one) http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/mak77@bonardo.net-4daeecf9928a/
Marco, macosx64-debug crashes right after starting. macosx64 starts but fails in the same way when deleting the history item.

https://crash-stats.mozilla.com/report/index/bp-b2d3b323-b002-4309-8c9e-2dc772110204
Stefan - can you link to one of the crashes you got with a normal nightly too please?  Want to make sure the crash is identical here.
(In reply to comment #19)
> Marco, macosx64-debug crashes right after starting.

hum, that is strange since it passed all tests on mac :( tomorrow I'll install it on my Mac and check.

Shawn, comment 10 has a crash report from Stefan
I don't know if this means anything, but I compiled mozilla from trunk and it fails on my profile with the following:

*** Compartment mismatch 0x107027600 vs. 0x12915f200
Assertion failure: compartment mismatched, at /Users/stefan/Mozilla/mozilla/js/src/jscntxtinlines.h:541

(I'll try to build b10 - My goal was to run it in GDB to get more info about the crash that this bug is about)
(In reply to comment #21)
> hum, that is strange since it passed all tests on mac :( tomorrow I'll install
> it on my Mac and check.
I don't think debug builds work unless you have the right packages installed locally, which most people won't have.

> Shawn, comment 10 has a crash report from Stefan
Whoops!  Not sure how I missed that...but yeah, it's the same crash still :/
(In reply to comment #23)
> (In reply to comment #21)
> > hum, that is strange since it passed all tests on mac :( tomorrow I'll install
> > it on my Mac and check.
> I don't think debug builds work unless you have the right packages installed
> locally, which most people won't have.

there was an opt in my trybuilds too.

btw, this build works pretty well on my Mac, since the changes are correct, even if they wouldn't fix the crash I'll push them.

Now, the compartment mismatch thing is expected to be fatal or to assert, but doesn't look related to this bug (that is cpp), I'd suggest to fie a bug aparts in core/Javascript engine if you have consistent str to reproduce it.

keeping investigating.
Comment on attachment 509858 [details] [diff] [review]
patch v1.0 (checked-in)

http://hg.mozilla.org/mozilla-central/rev/7cb3e9795d04

leaving the bug open to keep on the investigation.
Attachment #509858 - Attachment description: patch v1.0 → patch v1.0 (checked-in)
The only reported crash (so far) after the fix
https://crash-stats.mozilla.com/report/index/cb785485-117e-4646-a757-858f82110207
the stack is slightly different, the crash point is the same.
Depends on: 634796
Depends on: 637679
Yeah I'm still seeing this in b12 when deleting random history items. Let me know if I can do additional testing or debugging. I have a profile that has this behaviour.
I will post a new build shortly (working on related bug 637679)
Ok, the good news:

I could reproduce a crash triggered by deleting a specific history item. With this trybuild that crash does not happen anymore.

The bad news:

It is a different bug. The crashes that I see for this history item are happening in ToNewUnicode().

See https://crash-stats.mozilla.com/report/index/bp-93c69ba0-f3c5-4bff-8f46-552132110301
Oh looking at the stack trace of

https://crash-stats.mozilla.com/report/index/bp-93c69ba0-f3c5-4bff-8f46-552132110301

it seems that we actually mostly get through

AsyncGetBookmarksForURI<...>::HandleResult

but then crash in ToNewUnicode(), which is reported in

https://bugzilla.mozilla.org/show_bug.cgi?id=634796
I don't understand, did you crashed in ToNewUnicode with the build in comment 30? The build id doesn't seem the one from the try build.
I will test again and make sure I am less confusing this time.
Ok, tested again:

When running 4.0b12: I have a profile where deleting history items crashes the browser. However, it crashes PAST the top call in the stack trace for this bug (AsyncGetBookmarksForURI). See bug 634796, which is highly likely what I see.

When running your build, all is fine.

So I think this means that b12 actually had a fix for this bug but then triggered the next one (634796) which is fixed in the build that you gave me.
I assume this is fixed by bug 637957, since it involves the same code path and has same symptoms.

Yeah, b12 had a change in the behavior that changed the stack.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [softblocker] → [softblocker][fixed by bug 637957]
Target Milestone: --- → mozilla2.0
Duplicate of this bug: 638459
Depends on: 637957
Crash Signature: [@ AsyncGetBookmarksForURI<void (nsNavBookmarks::*)(mozilla::places::ItemChangeData), mozilla::places::ItemChangeData>::HandleResult ] [@ mozilla::places::ItemChangeData::ItemChangeData(mozilla::places::ItemChangeData const&)]
You need to log in before you can comment on or make changes to this bug.