634796 - Firefox 4.0b12pre Crash in nsNavBookmarks::NotifyItemChanged [@ ToNewUnicode ] [@ ToNewUnicode(nsACString_internal const&) ]

Status: RESOLVED FIXED

(Toolkit :: Places, defect)

Description

[Marcia Knous [:marcia]]

Seen while reviewing trunk crash stats. So far small volume crash affecting Mac only. http://tinyurl.com/47kw3z4 to the reports which started showing up in crash stats using the 2011020800 build.

Possible pushlog regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4c62984f12d1&tochange=3470891975c7

Frame 	Module 	Signature [Expand] 	Source
0 	XUL 	ToNewUnicode 	nsUTF8Utils.h:687
1 	XUL 	XPCConvert::NativeData2JS 	js/src/xpconnect/src/xpcconvert.cpp:437
2 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcprivate.h:3232
3 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
4 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
5 	XUL 	XUL@0xe2245a 	
6 	XUL 	nsNavBookmarks::NotifyItemChanged 	toolkit/components/places/src/nsNavBookmarks.cpp:2932
7 	XUL 	AsyncGetBookmarksForURI<void ,mozilla::places::ItemChangeData>::HandleResult 	toolkit/components/places/src/nsNavBookmarks.cpp:152
8 	XUL 	mozilla::storage::::CallbackResultNotifier::Run 	storage/src/mozStorageAsyncStatementExecution.cpp:100
9 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
10 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:195
11 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3126
12 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1613
13 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
14 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
15 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
16 	XUL 	array_extra 	js/src/jsinterpinlines.h:594
17 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
18 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
19 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
20 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
21 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
22 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
23 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
24 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2195
25 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
26 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
27 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
28 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:850
29 	XUL 	JS_CallFunctionValue 	js/src/jsapi.cpp:5166
30 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1672
31 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
32 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
33 	XUL 	XUL@0xe2245a 	
34 	XUL 	nsHttpChannel::OnDataAvailable 	netwerk/protocol/http/nsHttpChannel.cpp:4111
35 	XUL 	nsInputStreamPump::OnStateTransfer 	netwerk/base/src/nsInputStreamPump.cpp:510
36 	XUL 	nsInputStreamPump::OnInputStreamReady 	netwerk/base/src/nsInputStreamPump.cpp:400
37 	XUL 	nsInputStreamReadyEvent::Run 	xpcom/io/nsStreamUtils.cpp:112
38 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
39 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:195
40 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3126
41 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1613
42 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
43 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
44 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
45 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2195
46 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
47 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
48 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
49 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
50 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
51 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
52 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
53 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:850
54 	XUL 	JS_CallFunctionValue 	js/src/jsapi.cpp:5166
55 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1672
56 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
57 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
58 	XUL 	XUL@0xe2245a 	
59 	XUL 	nsNavHistory::RunInBatchMode 	toolkit/components/places/src/nsNavHistory.cpp:3987
60 	XUL 	NS_InvokeByIndex_P 	xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:195
61 	XUL 	XPCWrappedNative::CallMethod 	js/src/xpconnect/src/xpcwrappednative.cpp:3126
62 	XUL 	XPC_WN_CallMethod 	js/src/xpconnect/src/xpcwrappednativejsops.cpp:1613
63 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
64 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
65 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
66 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2195
67 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
68 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
69 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
70 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
71 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
72 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
73 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
74 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
75 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
76 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
77 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
78 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
79 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
80 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
81 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
82 	XUL 	js_fun_apply 	js/src/jsfun.cpp:2195
83 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
84 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
85 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
86 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
87 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
88 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
89 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
90 	XUL 	js_fun_call 	js/src/jsfun.cpp:2132
91 	XUL 	js::Interpret 	js/src/jscntxtinlines.h:697
92 	XUL 	js::RunScript 	js/src/jsinterp.cpp:649
93 	XUL 	js::Invoke 	js/src/jsinterp.cpp:729
94 	XUL 	js::ExternalInvoke 	js/src/jsinterp.cpp:850
95 	XUL 	JS_CallFunctionValue 	js/src/jsapi.cpp:5166
96 	XUL 	nsXPCWrappedJSClass::CallMethod 	js/src/xpconnect/src/xpcwrappedjsclass.cpp:1672
97 	XUL 	nsXPCWrappedJS::CallMethod 	js/src/xpconnect/src/xpcwrappedjs.cpp:588
98 	XUL 	PrepareAndDispatch 	xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
99 	XUL 	XUL@0xe2245a 	
100 	XUL 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:428
101 	XUL 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
102 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
103 	XUL 	NS_ProcessPendingEvents_P 	nsThreadUtils.cpp:200
104 	XUL 	nsBaseAppShell::NativeEventCallback 	widget/src/xpwidgets/nsBaseAppShell.cpp:132
105 	XUL 	nsAppShell::ProcessGeckoEvents 	widget/src/cocoa/nsAppShell.mm:399
106 	CoreFoundation 	CoreFoundation@0x4e400 	
107 	CoreFoundation 	CoreFoundation@0x4c5f8

Comment 2

[Mats Palmgren (inactive)]

This crash also occurs on Windows under the signature [@ ToNewUnicode(nsACString_internal const&) ].  These numbers should be added up to get the total volume.

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Screencast showing steps to reproduce it: http://screencast.com/t/dJ5EdQ3rI.

For me, on Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre, it's:

1. Typing "break" and letting http://www.casttv.com/video/nhglh91/breaking-bad-breaking-bad-s1e07-a-no-rough-stuff-type-deal-av-video autocomplete (it's favorited)
2. Hovering over the entry to highlight it, press shift+delete
3. Again type "break" and try to shift+delete again
4. Crash: https://crash-stats.mozilla.com/report/index/bp-6afba0b4-8e89-4bf4-8e8c-f03202110224

Comment 4

[Shawn Wilsher :sdwilsh]

Nice!  I wonder if those steps work on windows too...

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #4)
> Nice!  I wonder if those steps work on windows too...

I can't reproduce the crash with Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110222 Firefox/4.0b12pre, no.

Comment 6

[Chris AtLee [:catlee]]

I can reproduce this consistently on linux64.

1) open firefox
2) ctrl-t to open new tab
3) type 'tbpl'
4) arrow down, select first result
5) push shift-delete
6) ctrl-l
7) type 'tbpl' again
8) arrow down, select same result
9) push shift-delete
10) explode thusly:

#0  0x00007ffff6b67975 in (anonymous namespace)::AsyncGetBookmarksForURI<void (nsNavBookmarks::*)(mozilla::places::ItemChangeData const&), mozilla::places::ItemChangeData>::HandleResult (this=0x7fffc46f4da0, 
    aResultSet=0x7fffc46ec6e0)
    at /builds/slave/cen-lnx64-ntly/build/toolkit/components/places/src/nsNavBookmarks.cpp:152
#1  0x00007ffff6b369e3 in mozilla::storage::(anonymous namespace)::CallbackResultNotifier::Run (
    this=0x7fff00000001)
    at /builds/slave/cen-lnx64-ntly/build/storage/src/mozStorageAsyncStatementExecution.cpp:100
#2  0x00007ffff6d4cf64 in nsThread::ProcessNextEvent (this=0x7fffea73b480, mayWait=1, result=0x7fffffffd8bc)
    at /builds/slave/cen-lnx64-ntly/build/xpcom/threads/nsThread.cpp:633
#3  0x00007ffff6d1a2c6 in NS_ProcessNextEvent_P (thread=0x7ffff7951e60, mayWait=1) at nsThreadUtils.cpp:250
#4  0x00007ffff6c662c5 in mozilla::ipc::MessagePump::Run (this=0x7fffea738200, aDelegate=0x7fffed0a0200)
    at /builds/slave/cen-lnx64-ntly/build/ipc/glue/MessagePump.cpp:134
#5  0x00007ffff6d7e3c2 in RunHandler (this=0x7ffff7951e60)
    at /builds/slave/cen-lnx64-ntly/build/ipc/chromium/src/base/message_loop.cc:202
#6  MessageLoop::Run (this=0x7ffff7951e60)
    at /builds/slave/cen-lnx64-ntly/build/ipc/chromium/src/base/message_loop.cc:176
#7  0x00007ffff6bb19f1 in nsBaseAppShell::Run (this=0x7fffea736780)
    at /builds/slave/cen-lnx64-ntly/build/widget/src/xpwidgets/nsBaseAppShell.cpp:192
#8  0x00007ffff6a6c761 in nsAppStartup::Run (this=0x7fffe2e5ae00)
    at /builds/slave/cen-lnx64-ntly/build/toolkit/components/startup/src/nsAppStartup.cpp:220
#9  0x00007ffff629227a in XRE_main (argc=1, argv=<value optimized out>, aAppData=<value optimized out>)
    at /builds/slave/cen-lnx64-ntly/build/toolkit/xre/nsAppRunner.cpp:3781
#10 0x0000000000401b48 in ?? ()
#11 0x00007ffff2713c4d in __libc_start_main () from /lib/libc.so.6
#12 0x0000000000401909 in ?? ()
#13 0x00007fffffffe258 in ?? ()
#14 0x000000000000001c in ?? ()
#15 0x0000000000000001 in ?? ()
#16 0x00007fffffffe547 in ?? ()
#17 0x0000000000000000 in ?? ()

Comment 7

[Marco Bonardo [:mak]]

the stacks differs a bit, but looks like the steps to reproduce all involve deleting twice from the locationbar.

Comment 8

[Chris AtLee [:catlee]]

(In reply to comment #7)
> the stacks differs a bit, but looks like the steps to reproduce all involve
> deleting twice from the locationbar.

Not sure if this helps, but here's some additional detail...the awesomebar result I'm trying to delete is bookmarked, and has multiple tags associated with it. Some of the tags are shared with other bookmarks. The result never ends up getting deleted either.

Comment 9

[Scoobidiver (away)]

It is #9 top crasher on Mac OS X in 4.0b12.

Comment 10

[Marco Bonardo [:mak]]

I tried steps in both Linux 64 and Leopard, but didn't reproduce any crash so far

Comment 11

[Marco Bonardo [:mak]]

I reproduced once on snow leopard... It's interesting, I reproduced this in my official profile, but not in a new test profile. One of the differences betweek the two is that my official profile has Sync enabled, I disabled it and so far I've been unable to crash, I keep trying.
Stephen, Catlee, do you have Sync enabled? could you try copying your places.sqlite in a new profile and retry to crash?

Comment 12

[Marco Bonardo [:mak]]

After a bunch of tries with Sync disabled without success, I re-enabled it and crashed at the third try, so looks like we are firing a onItemChanged to the Sync bookmarks engine? I can't figure out why Sync would be different than any other observer though.
Will see if I can catch it in a debugger.

Comment 13

[Philipp von Weitershausen [:philikon]]

(In reply to comment #0)
> Seen while reviewing trunk crash stats. So far small volume crash affecting Mac
> only. http://tinyurl.com/47kw3z4 to the reports which started showing up in
> crash stats using the 2011020800 build.
> 
> Possible pushlog regression range:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4c62984f12d1&tochange=3470891975c7
> 
> Frame     Module     Signature [Expand]     Source
> 0     XUL     ToNewUnicode     nsUTF8Utils.h:687
> 1     XUL     XPCConvert::NativeData2JS    
> js/src/xpconnect/src/xpcconvert.cpp:437
> 2     XUL     nsXPCWrappedJSClass::CallMethod    
> js/src/xpconnect/src/xpcprivate.h:3232
> 3     XUL     nsXPCWrappedJS::CallMethod    
> js/src/xpconnect/src/xpcwrappedjs.cpp:588
> 4     XUL     PrepareAndDispatch    
> xpcom/reflect/xptcall/src/md/unix/xptcstubs_x86_64_darwin.cpp:153
> 5     XUL     XUL@0xe2245a     
> 6     XUL     nsNavBookmarks::NotifyItemChanged    
> toolkit/components/places/src/nsNavBookmarks.cpp:2932
> 7     XUL     AsyncGetBookmarksForURI<void
> ,mozilla::places::ItemChangeData>::HandleResult    
> toolkit/components/places/src/nsNavBookmarks.cpp:152
> 8     XUL     mozilla::storage::::CallbackResultNotifier::Run    
> storage/src/mozStorageAsyncStatementExecution.cpp:100
> 9     XUL     nsThread::ProcessNextEvent     xpcom/threads/nsThread.cpp:633

I suspect the trigger here is the fact that Sync spins the event loop occasionally. This can be harmful in observers (bug 633062).  Because bookmark observers aren't passed the bookmark GUID yet (bug 633274), we need to find out the GUID whenever a bookmark changed using SQL. Sadly our APIs are synchronous so we spin the event loop while we're waiting for async callback, though for many cases I suspect we don't actually need the synchronous event loop-spinning behaviour.

That said, as shameful as Sync's behaviour is here, it shouldn't cause us to crash, should it?

Comment 14

[Marco Bonardo [:mak]]

My suspicion is that spinning causes some release in the AsyncGetBookmarksForURI object and at the next HandleResult we jump at a random position. On Windows I was able to crash with the same steps and I ended up crasing in a d3d library.
I could probably workaround this thing easily, I'll proceed on 2 roads:
- try to check in a debugger what happens
- make a patch to increase solidity of AsyncGetBookmarksForURI notification path (collect ids in a local array and pass all of them to nsNavBookmarks, then let it just notify in a for loop)

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Hard blocking because the volume is high, though based on the fact that this is supposedly Sync only, not sure why that is.

Marco: think you can find and kill this one?

Comment 16

[Marco Bonardo [:mak]]

Taking for now since it's an unowned blocker.
I have a trybuild cooking in bug 637679 that could fix this thing for the current release, once it is complete I'll ask assistance to people that can reliably reproduce (I do now) to see if they can still reproduce.

The actual better fix would be to fix Places and Sync so that the latter won't need to spin the event loop to gather data, but this is FX.next stuff.

Comment 17

[Marco Bonardo [:mak]]

What I saw from debugging on Windows (since I was finally able to repro a crash on Windows) is that HandleResult is called, then HandleCompletion, then the destructor, then Storage seems to try to call HandleResult again, but since the object is destroyed it is causing random stuff to happen here. Spinning the loop could cause something like this imo, I imagine Storage is appending the completion event to the main thread.

Comment 18

[Marco Bonardo [:mak]]

could whoever was able to reproduce the cras try this build on the same profile please:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-91a962414422/

Comment 19

[Shawn Wilsher :sdwilsh]

(In reply to comment #17)
> What I saw from debugging on Windows (since I was finally able to repro a crash
> on Windows) is that HandleResult is called, then HandleCompletion, then the
> destructor, then Storage seems to try to call HandleResult again, but since the
> object is destroyed it is causing random stuff to happen here. Spinning the
> loop could cause something like this imo, I imagine Storage is appending the
> completion event to the main thread.
That's exactly what is going on there.  Storage thinks it is OK to release it's reference because the order of events is specified to be a certain way.

Comment 20

[Marco Bonardo [:mak]]

The steps I used to reproduce so far, in case people wants to help testing the build.
1. enable Sync
2. add 2 bookmarks to the toolbar, both with tags "a,e,i,o,u" (seems not relevant but complicates queries)
3. have just about:home tab
4. CMD+T to open a new tab, type part of the title of a bookmark, down, shift+backspace
5. repeat (4) for up to 5 times
6. close all tabs but about:home (CMD+W), then restart from (4)
7. after some tries this will crash

alternative steps are in comment 3 and comment 6

Comment 21

[mattburles]

i couldnt get this to crash on windows 7 64 bit and i am using the latest pre beta 13.

Comment 22

[Marco Bonardo [:mak]]

I think the crash is fully understood now:
0. mCallback is owned by AsyncExecuteStatements
1. CallbackResultNotifier fires and calls AsyncGetBookmarksForURI::HandleResult
2. Sync receives a notification and spins the main thread loop
3. at this point the CompletionNotifier event is run and it notifies AsyncGetBookmarksForURI::HandleCompletion, then it relases mCallback since it's no more useful according to pre-determined events ordering
4. now the original event proceeds in CallbackResultNotifier, but it is now notifying a zombie that could be completely or partially garbage

Comment 23

[Andreas Gal :gal]

Marco, do you have an ETA for the fix? We are down to the wire.

Comment 24

[Marco Bonardo [:mak]]

The patch in bug 637679 should be enough to fix this crash.
Today we'll look into bug 637957 that will also fix the bug in Storage where everything starts.
So, ETA is today.

Comment 25

[Shawn Wilsher :sdwilsh]

(In reply to comment #24)
> The patch in bug 637679 should be enough to fix this crash.
> Today we'll look into bug 637957 that will also fix the bug in Storage where
> everything starts.
> So, ETA is today.
For what it's worth, bug 637957 seems a lot safer to take than bug 637679.  I'll look more closely later today.

Comment 26

[Marco Bonardo [:mak]]

(In reply to comment #25)
> For what it's worth, bug 637957 seems a lot safer to take than bug 637679. 
> I'll look more closely later today.

Imho currently both are safe, the first patch in bug 637679 was larger, but current patch is pretty much trivial, just notifies in HandleCompletion rather than in HandleResult.  Notifying in HandleResult still makes me nervous.

So far both are good to fix this crash, one from caller side (Places) and one from backend side (Storage).

Comment 27

[Johnathan Nightingale [:johnath]]

(In reply to comment #26)
> (In reply to comment #25)
> > For what it's worth, bug 637957 seems a lot safer to take than bug 637679. 
> > I'll look more closely later today.
> 
> Imho currently both are safe, the first patch in bug 637679 was larger, but
> current patch is pretty much trivial, just notifies in HandleCompletion rather
> than in HandleResult.  Notifying in HandleResult still makes me nervous.
> 
> So far both are good to fix this crash, one from caller side (Places) and one
> from backend side (Storage).

sdwilsh - eta on those reviews?

Comment 28

[Johnathan Nightingale [:johnath]]

Oop - sorry for churn - asked and answered above - just didn't reload bug.

Comment 29

[Chris AtLee [:catlee]]

(In reply to comment #18)
> could whoever was able to reproduce the cras try this build on the same profile
> please:
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/[e-mail]-91a962414422/

It no longer crashes on this build for me.  It also doesn't delete the awesomebar result like I expect, maybe that's because it's bookmarked as well?

Comment 30

[Marco Bonardo [:mak]]

(In reply to comment #29)
> It no longer crashes on this build for me.  It also doesn't delete the
> awesomebar result like I expect, maybe that's because it's bookmarked as well?

yes, it won't be removed because it's a bookmark, I actually noticed that graphically this is not consistent across every OS (some remove the entry and then add it back some not). But this is not related to this bug.
Thanks for checking.

Comment 31

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Hey I have a profile that crashes as described in this report on 4.0b12 when I delete a history item.

I tested a more recent nightly and the that crash does not happen anymore for me.

I can share the profile if you want to do more testing.

Comment 32

[Marco Bonardo [:mak]]

Thanks, should not be needed currently, since I reproduced locally and we have a good analysis of the crash.

Comment 33

[Marco Bonardo [:mak]]

fixed by bug 637957

Comment 34

[chris hofmann]

here is history for report days and buildid where we have seen intro and ramp up of volume for ToNewUnicode.  looks like the ramp might be tied to ramp of b12

date     total    breakdown by build
         crashes  count build, count build, ...

[none prior]  
20110205   
20110206   
20110207 3 4.0b12pre2011020703 	3 , 
20110208 2  	1 4.0b12pre2011020803, 
        		1 4.0b12pre2011020703, 
20110209 1 4.0b12pre2011020803 	1 , 
20110210   
20110211   
20110212   
20110213 1 4.0b12pre2011020803 	1 , 
20110214 7  	4 4.0b12pre2011021003, 
        		2 4.0b12pre2011021303, 	1 4.0b12pre2011021403, 
20110215 1 4.0b12pre2011021303 	1 , 
20110216 4  	2 4.0b12pre2011021503, 
        		2 4.0b12pre2011021303, 
20110217   
20110218   
20110219 3  	2 4.0b12pre2011021803, 
        		1 4.0b12pre2011021712, 
20110220   
20110221 1 4.0b12pre2011022003 	1 , 
20110222   
20110223   
20110224 4 4.0b12pre2011022219 	4 , 
20110225 1 4.0b122011022220 	1 , 
20110226 9 4.0b122011022220 	9 , 
20110227 39  	33 4.0b122011022220, 
        		6 4.0b12pre2011022219, 
20110228 38  	36 4.0b122011022220, 
        		2 4.0b13pre2011022803,

Comment 35

[chris hofmann]

history for          ToNewUnicode.nsACString_internal.const..
date     total    breakdown by build
         crashes  count build, count build, ...

[none prior]
20110207   
20110208   
20110209 7  	3 4.0b12pre2011020803, 
        		2 4.0b12pre2011020603, 	1 4.0b12pre2011020903, 
        		1 3.6.132010120307, 
20110210 1 4.0b12pre2011021003 	1 , 
20110211 13  	10 4.0b12pre2011021003, 
        		2 4.0b12pre2011021103, 	1 4.0b12pre2011020903, 
20110212   
20110213 2 4.0b12pre2011021203 	2 , 
20110214 2  	1 4.0b12pre2011021403, 
        		1 4.0b12pre2011021103, 
20110215 1 4.0b12pre2011021503 	1 , 
20110216   
20110217 10  	5 4.0b12pre2011020803, 
        		4 4.0b12pre2011021603, 	1 4.0b12pre2011021703, 
20110218 2  	1 4.0b12pre2011021703, 
        		1 4.0b12pre2011021603, 
20110219 1 4.0b12pre2011021803 	1 , 
20110220   
20110221 8  	3 4.0b12pre2011022103, 
        		2 4.0b12pre2011021203, 	2 3.6.132010120307, 
        		1 4.0b12pre2011021814, 
20110222 1 4.0b12pre2011022203 	1 , 
20110223 5  	3 4.0b12pre2011022003, 
        		1 4.0b62010091408, 	1 4.0b13pre2011022303, 
20110224   
20110225 6  	5 4.0b12pre2011022003, 
        		1 4.0b13pre2011022303, 
20110226 12  	6 4.0b13pre2011022503, 
        		4 4.0b12pre2011022203, 	1 4.0b13pre2011022603, 
        		1 4.0b12pre2011022003, 
20110227   
20110228