629120 - Crash [@ mozilla::storage::AsyncExecuteStatements::Run] with Yoono 7.6.3 and below

Status: RESOLVED WORKSFORME

(Firefox :: Extension Compatibility, defect)

Description

[Nicolás Lichtmaier]

Firefox crashes at the moment it starts. It doesn't happen in "safe mode", maybe is realted to the Yoono extension (I've read they have to change async/threading code for the latest Firefox betas)...

The crash report is: bp-b0ab356b-6104-4a3b-bc26-57cc72110126 .

Comment 1

[timeless]

Signature	mozilla::storage::AsyncExecuteStatements::Run
UUID	b0ab356b-6104-4a3b-bc26-57cc72110126
Time 	2011-01-26 11:49:50.36056
Uptime	11
Last Crash	677 seconds (11.3 minutes) before submission
Install Age	11 seconds since version was first installed.
Product	Firefox
Version	4.0b10
Build ID	20110121161649
Branch	2.0
OS	Linux
OS Version	0.0.0 Linux 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64
CPU	amd64
CPU Info	family 6 model 15 stepping 13
Crash Reason	SIGSEGV
Crash Address	0x119
User Comments	
Processor Notes 	
EMCheckCompatibility	False
Bugzilla - Report this Crash
Related Bugs

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	mozilla::storage::AsyncExecuteStatements::Run 	storage/src/mozStorageStatementData.h:140
1 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
2 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
3 	libxul.so 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:277
4 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
5 	libpthread-2.12.1.so 	libpthread-2.12.1.so@0x7970 	

Show/hide other threads
Thread 0
Frame 	Module 	Signature [Expand] 	Source
0 	libxul.so 	nsCSSFrameConstructor::BeginUpdate 	layout/base/nsCSSFrameConstructor.cpp:8300
1 	libxul.so 	mozilla::css::RestyleTracker::ProcessRestyles 	layout/base/RestyleTracker.cpp:172
2 	libxul.so 	nsCSSFrameConstructor::ProcessPendingRestyles 	layout/base/nsCSSFrameConstructor.cpp:11673
3 	libxul.so 	PresShell::FlushPendingNotifications 	layout/base/nsPresShell.cpp:4864
4 	libxul.so 	nsDocument::FlushPendingNotifications 	content/base/src/nsDocument.cpp:6448
5 	libxul.so 	nsDocument::FlushPendingNotifications 	content/base/src/nsDocument.cpp:6443
6 	libxul.so 	nsDocument::FlushPendingNotifications 	content/base/src/nsDocument.cpp:6443
7 	libxul.so 	nsGenericElement::GetPrimaryFrame 	content/base/src/nsGenericElement.cpp:3761
8 	libxul.so 	nsGenericElement::GetStyledFrame 	content/base/src/nsGenericElement.cpp:1479
9 	libxul.so 	nsGenericHTMLElement::GetOffsetRect 	content/html/content/src/nsGenericHTMLElement.cpp:512
10 	libxul.so 	nsGenericHTMLElement::GetOffsetWidth 	content/html/content/src/nsGenericHTMLElement.cpp:643
11 	libxul.so 	nsIDOMNSHTMLElement_GetOffsetWidth 	dom_quickstubs.cpp:20786
12 	libxul.so 	js_GetPropertyHelper 	js/src/jscntxtinlines.h:736
13 	libxul.so 	InlineGetProp 	js/src/methodjit/StubCalls.cpp:1912
14 	libxul.so 	js::mjit::stubs::GetProp 	js/src/methodjit/StubCalls.cpp:1930
15 		@0x7fce57f538c0 	
16 	libxul.so 	js::mjit::JaegerShot 	js/src/methodjit/MethodJIT.cpp:748
17 	libxul.so 	js::Invoke 	js/src/jsinterp.cpp:654
18 	libxul.so 	js::ExternalInvoke 	js/src/jsinterp.cpp:858
19 	libxul.so 	JS_CallFunctionValue 	js/src/jsinterp.h:961
20 	libxul.so 	nsJSContext::CallEventHandler 	dom/base/nsJSEnvironment.cpp:2005
21 	libxul.so 	nsGlobalWindow::RunTimeout 	dom/base/nsGlobalWindow.cpp:9069
22 	libxul.so 	nsGlobalWindow::TimerCallback 	dom/base/nsGlobalWindow.cpp:9414
23 	libxul.so 	nsTimerImpl::Fire 	xpcom/threads/nsTimerImpl.cpp:425
24 	libxul.so 	nsTimerEvent::Run 	xpcom/threads/nsTimerImpl.cpp:517
25 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:633
26 	libxul.so 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
27 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
28 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:202
29 	libxul.so 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:195
30 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:217
31 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3773
32 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:158
33 	libc-2.12.1.so 	libc-2.12.1.so@0x1ed8d 	
34 	firefox-bin 	Output 	browser/app/nsBrowserApp.cpp:77
35 		@0x7fffb017799d

Comment 2

[Scoobidiver (away)]

It is #1 top crasher on Linux in 4.0b10.

There is a clear correlation with the Yoono extension:
100% (32/32) vs.  28% (67/236) {d9284e50-81fc-11da-a72b-0800200c9a66} (Yoono - Socialize Your Browser, https://addons.mozilla.org/addon/1833) (7.6.0)

Comment 3

[Nicolás Lichtmaier]

This was written by someone in a previous Yoono bugreport:

-----
They made the thread manager javascript api effectively useless by forbidding passing objects between threads.
We used it so that the requests to the database do not freeze the ui.
We thought we could use chrome workers but for now they can't work in a resource out of a window context which is a registered bug but anyway they can't access the Components api for storage. And probably never will...
Besides mozilla will not implement the html5 storage api since it's on hold by w3c.
So for ff4 we now use the asynchronous storage api but this leaves to the main thread the creation and binding of statements as well as the parsing of the requests results to build the data structures we need...
And this is not good for the ui smoothness.
Mozilla is not too concerned because the js thread api was very seldom used... 

Here: http://support.yoono.com/yoono/topics/incompatible_with_firefox_4b7

Comment 4

[Shawn Wilsher :sdwilsh]

I can't reproduce this crash at all.  If someone can get me steps to reproduce, this will get a lot easier to fix.

On an unrelated note, this add-on seems to leak every single url it ever loads and has tons of JavaScript strict errors.

Comment 5

[Nicolás Lichtmaier]

I tried again, I reenabled Yoono here and I got another crash in the same place: bp-e0af25b9-4afb-4610-a9c1-ce3f02110203

Comment 6

[Shawn Wilsher :sdwilsh]

(In reply to comment #5)
> I tried again, I reenabled Yoono here and I got another crash in the same
> place: bp-e0af25b9-4afb-4610-a9c1-ce3f02110203
What I really need here is steps to reproduce from a clean profile.  Once I get that, I can very likely fix this crash.  I tried for about an hour yesterday to reproduce this with no luck.

Comment 7

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

Soft blocking - if we can't fix the crash, we might just want to blocklist Yoono. :/

Comment 8

[Xavier]

(In reply to comment #4)
> I can't reproduce this crash at all.  If someone can get me steps to reproduce,
> this will get a lot easier to fix.
> 
> On an unrelated note, this add-on seems to leak every single url it ever loads
> and has tons of JavaScript strict errors.

Hi Shawn, can you send me copies of the error messages you are seeing ? I'm not seeing them, and would like to investigate, thanks.

Comment 9

[Xavier]

(In reply to comment #7)
> Soft blocking - if we can't fix the crash, we might just want to blocklist
> Yoono. :/

Hi Mike,

We (at Yoono :) are now using the async statement execution since the JS thread API was disabled in FF4 because it was not safe enough.

We would be really sad to see Yoono blocked on every platform because of a bug that can't be fixed in Mozilla API on Linux.

The loss of the JS Thread API between two betas of FF4 was hard enough on us.
I first wanted to use the Chrome Workers, but at the time, they were unable to work from within resources files, and unable to use XPCOM anyway (like storage).

If you could provide some direction (as I was offered in the discussion about the JS Thread API removal, but then never got) as to a better way to make sqlite requests without blocking the UI, I would gladly explore a new implementation.

Thanks if you can help!

Comment 10

[Dietrich Ayala (:dietrich)]

Hi Xavier. You should be able to use async statement execution without crashing. Finding out why that's happening seems to be the right way forward. Can you post the relevant code from Yoono somewhere?

Comment 11

[Xavier]

Yes I can do that, but I would rather email it to someone (you ?) than post it here.

However, I want to insist that we do use async statements without crashing, and that the issue only (?) seems to occur on Linux.
(Let me know if I'm wrong, I'm not too used to searching the crash report database)

I've also found some occurrences of the exact same async statement execute crash report without Yoono being present.

Comment 12

[Scoobidiver (away)]

It is now only #10 top crasher on Linux in 4.0b10. It happens mainly close to startup.
There are only 2 crashes on Windows but not with the Yonoo extension.
There are no crashes on Mac OS X.

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0b10&platform=linux&query_search=signature&query_type=exact&query=&range_value=4&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=mozilla%3A%3Astorage%3A%3AAsyncExecuteStatements%3A%3ARun

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Xavier, you can absolutely mail the code to Shawn Wilsher (The Storage module owner, see above), you don't have to attach it here if you don't feel comfortable doing that.
Also, you could try to run your extension in a debug Firefox to check if you get any assertions from Storage.

Comment 14

[Xavier]

Thanks Marco, I just emailed Shawn.

Comment 15

[Shawn Wilsher :sdwilsh]

(In reply to comment #9)
> We would be really sad to see Yoono blocked on every platform because of a bug
> that can't be fixed in Mozilla API on Linux.
I think we can block on a per-platform basis.  I hadn't noticed this was Linux only, which makes sense why I could not reproduce this (on Windows).

Comment 16

[Shawn Wilsher :sdwilsh]

Nothing jumped out at me while looking at the code.  I have tried to reproduce this in a 32-bit fedora VM debug build (beta 10 code), and have been unable to do so.  I've got twitter, facebook, flickr, and yahoo messenger accounts added.

Nicolás - what accounts do you have enabled in the add-on, by chance?

Comment 17

[Shawn Wilsher :sdwilsh]

Attachment: stdout output

I mentioned leaking urls in comment 4.  This is the stdout output of Firefox, which contains the list of urls leaked at shutdown.  This doesn't happen when the add-on is not installed, so it's probably holding onto something longer than it should.

Comment 18

[Xavier]

Thanks Shawn, I'll investigate this.

Just to be sure, you are saying that when Yoono is not installed, you get no Leaked Url at all ? Or just not the ones from Yoono ?
I'm seeing urls from xbl bindings that Yoono is not even using (like colorpicker for instance), so I'm not too sure about the significance of these.
Even .png and .css urls are reported, for which I'm not sure what can be done at an extension developer level.
Can you direct me to some documentation about the meaning of such reported "Leaked URLs"
Thanks a lot for your help.

Comment 19

[Shawn Wilsher :sdwilsh]

(In reply to comment #18)
> Just to be sure, you are saying that when Yoono is not installed, you get no
> Leaked Url at all ? Or just not the ones from Yoono ?
I get no leaked URLs.

> I'm seeing urls from xbl bindings that Yoono is not even using (like
> colorpicker for instance), so I'm not too sure about the significance of these.
> Even .png and .css urls are reported, for which I'm not sure what can be done
> at an extension developer level.
The URLs are likely from the 10 leaked windows also visible in that log.  ++DOMWINDOW and --DOMWINDOW lines should be equal (and there is a running total for each line too).  The last line says:
--DOMWINDOW == 10 (0xa3a0c104) [serial = 64] [outer = (nil)] [url = chrome://yoonosb/content/js/srv/emptyDocument.html#locales]

That line tells us that we are destroying a DOMWINDOW (--DOMWINDOW), it has no outer window (outer = (nil)), and the url of the window we are destroying is chrome://yoonosb/content/js/srv/emptyDocument.html#locales

You see the xbl leaks too because the windows that are leaked are likely using a resource at that url.

Comment 20

[Xavier]

Thanks a lot Shawn for the detailed explanation, that will help a lot.

Comment 21

[Nicolás Lichtmaier]

(In reply to comment #16)
> Nothing jumped out at me while looking at the code.  I have tried to reproduce
> this in a 32-bit fedora VM debug build (beta 10 code), and have been unable to
> do so.  I've got twitter, facebook, flickr, and yahoo messenger accounts added.
> 
> Nicolás - what accounts do you have enabled in the add-on, by chance?

I've enabled Foursquare as well...

Comment 22

[Shawn Wilsher :sdwilsh]

Can't seem to get foursquare integration to work.  If someone can get me steps to reproduce from a clean profile, it'd be a huge help.

Comment 23

[Xavier]

(In reply to comment #22)
> Can't seem to get foursquare integration to work.  If someone can get me steps
> to reproduce from a clean profile, it'd be a huge help.

Hi Shawn, 

Do not focus on Foursquare, I got the crash on a Ubuntu in VMWare, without adding Foursquare, I had only added Twitter.
I tried again on a new profile, and then it didn't crash after adding Twitter (and several relaunches).
It may need some amount of data in the database to trigger it, I don't know, will let you know if I find anything to reproduce it.

Comment 24

[Xavier]

(In reply to comment #22)
> Can't seem to get foursquare integration to work.  If someone can get me steps
> to reproduce from a clean profile, it'd be a huge help.

Shawn, I'll email you my yoono directory (Firefox profile subdirectory), and if you replace yours with mine, you should be able to reproduce the issue.
I have one that crashes and one that does not, both have the same Twitter account configured, but one is brand new (not crashing), the other several days old.
I hope this will help, let me know.

Comment 25

[Shawn Wilsher :sdwilsh]

That doesn't seem to do the trick for me either.  I'm running Yoono 7.6.2, copied the yoono folder you sent me to my profile directory, and set the preference you also said I needed to set.  The add-on is not functional now, however.  It just sits there at the "Loading, please wait..." screen.  In the error console, I get these errors:
Error: exception [resource://yoono/yoonoStorageAsync@68] 6212ms, message : Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [mozIStorageConnection.createStatement]
name : NS_ERROR_FAILURE
stack :  - resource://yoono/yoonoStorageAsync.js@83 : 
 - resource://yoono/yoonoStorageAsync.js@181 : 
 - resource://yoono/yoonoStorageAsync.js@163 : 
 - resource://yoono/yoonoYEXTIF.js@322 : 
 - chrome://yoonosb/content/js/interfaces.js@1 : 
 - chrome://yoonosb/content/js/srv/src/storageManager.js@1 : 
 - chrome://yoonosb/content/js/srv/accMgr/requests/socialzine/url.js@1 : 
 - chrome://yoonosb/content/js/srv/accMgr/requests/socialzine/url.js@1 : 
Source File: resource://yoono/yoonoStorageAsync.js
Line: 69

Error: error [resource://yoono/yoonoStorageAsync@91] 6213ms, no such table: url_data
Source File: resource://yoono/yoonoStorageAsync.js
Line: 92

(above two repeated twice)

Error: exception [sb::srv/src/accountsManager@1] 91021ms, message : accountsManager not ready
name : Error
stack : getPlugins()@chrome://yoonosb/content/js/srv/src/accountsManager.js:1
()@chrome://yoonosb/content/friends2/js/yoodget.js:1
("idleService","blur","idle")@chrome://yoonosb/content/friends2/js/yoodget.js:1
([object XPCWrappedNative_NoHelper],"idle","30")@chrome://yoonosb/content/js/srv/browser/idle.js:1
Source File: chrome://yoonosb/content/js/srv/src/accountsManager.js
Line: 2

Error: exception [sb::srv/src/accountsManager@1] 100507ms, message : accountsManager not ready
name : Error
stack : getPlugins()@chrome://yoonosb/content/js/srv/src/accountsManager.js:1
()@chrome://yoonosb/content/friends2/js/yoodget.js:1
("idleService","blur","back")@chrome://yoonosb/content/friends2/js/yoodget.js:1
([object XPCWrappedNative_NoHelper],"back","0")@chrome://yoonosb/content/js/srv/browser/idle.js:1
Source File: chrome://yoonosb/content/js/srv/src/accountsManager.js
Line: 2

This is all in a debug build of beta 10:
Mozilla/5.0 (X11; Linux i686; rv:2.0b10) Gecko/20110207 Firefox/4.0b10

Comment 26

[Xavier]

Hi Shawn

I'm puzzled for 2 reasons:

- This error shows that the add-on is building the database, which it should not since it's already present in the folder I sent you.
Could happen if the value in prefs.js does not match the database name in the folder.

- It mentions a table name (url_data) that does not belong to Yoono 7.6.2 but to the next not yet released version.

I'm investigating what can cause this...
Thanks for your patience and help

Comment 27

[Shawn Wilsher :sdwilsh]

(In reply to comment #26)
> - This error shows that the add-on is building the database, which it should
> not since it's already present in the folder I sent you.
> Could happen if the value in prefs.js does not match the database name in the
> folder.
Are there any other preferences that I need to set apart from the one you sent me originally?

Comment 28

[Xavier]

(In reply to comment #27)
> (In reply to comment #26)
> > - This error shows that the add-on is building the database, which it should
> > not since it's already present in the folder I sent you.
> > Could happen if the value in prefs.js does not match the database name in the
> > folder.
> Are there any other preferences that I need to set apart from the one you sent
> me originally?

No, and I just tried it again, replaced my yoono profile with the one I sent, edited the prefs.js file, then launched FF... All was fine...
(Just in case, FF needs to be closed before you replace the directory and edit the prefs.js file).
I guess you could wipe out the yoono directory to get rid of the error, start FF to have it create a new profile directory, then replace it...

Comment 29

[Shawn Wilsher :sdwilsh]

Tried to let the add-on build up an existing folder, and then quit and replace, and I still get the same errors.

Comment 30

[Scoobidiver (away)]

May be fixed by bug 635482.

Comment 31

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

** PRODUCT DRIVERS PLEASE NOTE **

This bug is one of 7 automatically changed from blocking2.0:final+ to blocking2.0:.x during the endgame of Firefox 4 for the following reasons:

 - it was marked as a soft blocking issue without a requirement for beta coverage

Comment 32

[Scoobidiver (away)]

It is #2 top crasher on Linux in 4.0RC1.

Comment 33

[gray.graff]

firefox 4.0. Bug still here

Comment 34

[Scoobidiver (away)]

The latest correlations by add-on version are:
     99% (331/336) vs.  16% (409/2585) {d9284e50-81fc-11da-a72b-0800200c9a66} (Yoono - Socialize Your Browser, https://addons.mozilla.org/addon/1833)
          0% (0/336) vs.   0% (3/2585) 7.6.0
         94% (316/336) vs.  15% (384/2585) 7.6.2
          4% (15/336) vs.   1% (22/2585) 7.6.3

Comment 35

[alex_mayorga]

FWIW I just crashed 3 times with Yoono 7.6.3 on Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110322 Firefox/4.0b13pre ID:20110322044950

bp-722c8819-13df-4861-84c5-2882f2110329
bp-75a5fa5b-40a3-4973-a8b3-c45812110329
bp-bc653b17-543b-4b14-98ac-096942110329

Please let me know if there's anything I can help with.

Comment 36

[(mostly gone) XtC4UaLL [:xtc4uall]]

FYI, on Bug 673521 a similar Stack can be seen with the Friendly Gaming Simplifier Extension causing Crashes against Firefox 5.0.1 on MacOS.

Comment 37

[Sheila Mooney]

Still there but not a top crash. Removing the keyword.

Comment 38

[Tracy Walker [:tracy]]

Reports show this is happening recently almost exclusively on 4.0b2.  A couple of recent reports on 21.0 on XP sp2.

Nothing to show this is happening on current builds on up to date systems.