Closed Bug 600079 Opened 15 years ago Closed 15 years ago

Crash in [@ @0x0 | mozilla::gl::GLContext::MarkDestroyed() ]

Categories

(Core :: Graphics: CanvasWebGL, defect)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: marcia, Assigned: bjacob)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

zero GL symbols if initialization failed
928 bytes, patch
vlad
: review+
joe
: approval2.0+
Details | Diff | Splinter Review
Seen while reviewing crash stats, and crashes started showing up using the 2010092300 trunk build. Crashes are Windows only - XP and 7. http://tinyurl.com/2c6yn7e links to the crashes. This is a low volume trunk crash. Frame Module Signature [Expand] Source 0 @0x0 1 xul.dll mozilla::gl::GLContext::MarkDestroyed gfx/thebes/GLContext.cpp:814 2 xul.dll mozilla::gl::GLContextWGL::~GLContextWGL gfx/thebes/GLContextProviderWGL.cpp:253 3 xul.dll mozilla::gl::GLContextWGL::`vector deleting destructor' 4 xul.dll mozilla::gl::GLContext::Release gfx/thebes/GLContext.h:352 5 xul.dll nsRefPtr<mozilla::gl::GLContextWGL>::assign_assuming_AddRef obj-firefox/dist/include/nsAutoPtr.h:957 6 xul.dll nsRefPtr<mozilla::gl::GLContextWGL>::assign_with_AddRef obj-firefox/dist/include/nsAutoPtr.h:941 7 xul.dll mozilla::gl::GLContextProviderWGL::GetGlobalContext gfx/thebes/GLContextProviderWGL.cpp:731 8 xul.dll mozilla::gl::WGLLibrary::EnsureInitialized gfx/thebes/GLContextProviderWGL.cpp:208 9 xul.dll mozilla::gl::GLContextProviderWGL::CreateOffscreen gfx/thebes/GLContextProviderWGL.cpp:669 10 xul.dll mozilla::WebGLContext::SetDimensions content/canvas/src/WebGLContext.cpp:357 11 xul.dll nsHTMLCanvasElement::UpdateContext content/html/content/src/nsHTMLCanvasElement.cpp:506 12 xul.dll nsHTMLCanvasElement::GetContext content/html/content/src/nsHTMLCanvasElement.cpp:439 13 xul.dll nsIDOMHTMLCanvasElement_GetContext obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:21000 14 xul.dll js::Interpret js/src/jsinterp.cpp:4477 15 xul.dll js::Invoke js/src/jsinterp.cpp:592 16 xul.dll js::ExternalInvoke js/src/jsinterp.cpp:622 17 xul.dll nsJSContext::CallEventHandler dom/base/nsJSEnvironment.cpp:2140 18 xul.dll nsJSEventListener::HandleEvent dom/src/events/nsJSEventListener.cpp:228 19 xul.dll nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1112 20 xul.dll nsEventListenerManager::HandleEventInternal content/events/src/nsEventListenerManager.cpp:1208 21 xul.dll nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:341 22 @0x12d83b One user crashed multiple times on http://html5test.com/ - https://crash-stats.mozilla.com/report/index/326fab2d-49f2-4955-af91-f80552100923 is that report.
I was thinking that this was probably a dupe of bug 592769. Then I checked your search: https://crash-stats.mozilla.com/report/list?version=Firefox%3A4.0b7pre&build_id=&query_search=signature&query_type=exact&query=&date=2010-09-27%2015%3A00%3A00&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=&signature=%400x0%20|%20mozilla%3A%3Agl%3A%3AGLContext%3A%3AMarkDestroyed%28%29&missing_sig=&page=1 It appears that it stopped crashing on September 27. This is the day when bug 592769 was landed. So, concluding it is a dupe; feel free to reopen if crashes occur again.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Argh, this search was clamped to Sep. 27. This new search, going up to Oct. 4: https://crash-stats.mozilla.com/report/list?version=Firefox%3A4.0b7pre&build_id=&query_search=signature&query_type=exact&query=&date=2010-10-04%2015%3A00%3A00&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=&signature=%400x0%20|%20mozilla%3A%3Agl%3A%3AGLContext%3A%3AMarkDestroyed%28%29&missing_sig=&page=1 Shows that while it has mostly stopped on Sep. 27, we do have a couple of crashes on Oct. 2. For example: https://crash-stats.mozilla.com/report/index/f6208068-d425-4927-8527-dc0d12101002 0 @0x0 1 xul.dll mozilla::gl::GLContext::MarkDestroyed gfx/thebes/GLContext.cpp:820 2 xul.dll mozilla::gl::GLContextWGL::~GLContextWGL gfx/thebes/GLContextProviderWGL.cpp:253 3 xul.dll mozilla::gl::GLContextWGL::`scalar deleting destructor' 4 xul.dll mozilla::gl::GLContext::Release gfx/thebes/GLContext.h:352 5 xul.dll nsRefPtr<mozilla::gl::GLContextWGL>::assign_assuming_AddRef obj-firefox/dist/include/nsAutoPtr.h:957 6 xul.dll nsRefPtr<mozilla::gl::GLContextWGL>::assign_with_AddRef obj-firefox/dist/include/nsAutoPtr.h:941 7 xul.dll mozilla::gl::GLContextProviderWGL::GetGlobalContext gfx/thebes/GLContextProviderWGL.cpp:731 8 xul.dll mozilla::gl::WGLLibrary::EnsureInitialized gfx/thebes/GLContextProviderWGL.cpp:208 9 xul.dll mozilla::gl::GLContextProviderWGL::CreateOffscreen gfx/thebes/GLContextProviderWGL.cpp:669 10 xul.dll mozilla::WebGLContext::SetDimensions content/canvas/src/WebGLContext.cpp:357 11 xul.dll nsHTMLCanvasElement::UpdateContext content/html/content/src/nsHTMLCanvasElement.cpp:506 12 xul.dll nsHTMLCanvasElement::GetContext content/html/content/src/nsHTMLCanvasElement.cpp:439 13 xul.dll nsIDOMHTMLCanvasElement_GetContext obj-firefox/js/src/xpconnect/src/dom_quickstubs.cpp:21000 14 mozjs.dll js::Interpret js/src/jsinterp.cpp:4625
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
OK, I really need someone to reproduce this in a debug build. It seems as though Release is called on a null pointer, but we need a debug build to tell. If this is confirmed, the next question would be: is this OK? If yes, then the THEBES_INLINE_DECL_THREADSAFE_REFCOUNTING macro, which implements this Release function, is wrong. Should it check for null pointer? http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxTypes.h#94
Got this crash 3 times in a row now while trying to visit http://bodybrowser.googlelabs.com/ build: http://hg.mozilla.org/mozilla-central/rev/f11f7ed625ba Version: 4.0b9pre Mozilla/5.0 (Windows NT 5.1; rv:2.0b9pre) Gecko/20101215 Firefox/4.0b9pre
Still can't reproduce in bodybrowser. Keep the testcases coming :-)
Still have the problem with the nightly build, now on 12/16 Is there a kind of debug build to try somethings for you? I tried the http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-debug/1292508923/firefox-4.0b9pre.en-US.win32.installer.exe but that installer only has a firefox.exe from 12/16 and the rest of the files are from 1/1/2010 and refuses to start at all.
On WinXP SP3 x86 nightly build 20101229030346: http://support.mozilla.com/ crashes. (extreme irony or what?) http://crash-stats.mozilla.com/report/index/bp-d85128bb-6b30-4b3b-8c09-e6b392101230
blocking2.0: --- → ?
I'm experiencing this crash every time I try to open about:support page. I don't know if it helps, but here is the most recent crash report: http://crash-stats.mozilla.com/report/index/bp-76db4542-5d02-4075-bce8-d6e5f2110102
Yes, because about:support creates a WebGL context to get the WebGL information. I am almost sure that this will be fixed by bug 616416. Will do it asap...
Depends on: 616416
Ah! No, sorry, ignore me --- this is a windows crash, not linux.
No longer depends on: 616416
Instead, this bug will go away when we ship the DirectX runtime so ANGLE can be used for rendering on Windows. (is there a bug for that? please mark as depending on it)
79 is a bit low on topcrash, so I think we can release with this, but hopefully rendering using ANGLE makes it a moot point.
blocking2.0: ? → -
So MarkDestroyed makes GL calls unless IsDestroyed() returns false; IsDestroyed() only returns FALSE if fUseProgram is false. That symbol is somewhere in the middle of the symbols that we query though, so we could end up in a state where we query that symbol successfully, but bail later on due to capabilities or other issues. In initialization, if init fails, we really should be calling Zero on the symbols struct to ensure that IsDestroyed() always returns TRUE if we never managed to initialize in the first place.
I would definitely approve a patch that fixes that!
Good idea, here's a small patch doing this in InitWithPrefix.
Attachment #501460 - Flags: review?(vladimir)
Attachment #501460 - Flags: approval2.0+
http://hg.mozilla.org/mozilla-central/rev/efad321b7a2e can you guys check if the problem is fixed in tomorrow's nightly build?
turns out that this signature is the top crash for people hitting http://bodybrowser.googlelabs.com/ and that might have be the reason, or combination, for part of the recent ramp up. maybe we also turn parts of bodybrowser into a test case for this bug or in general.
urls from the last few days 209 http://bodybrowser.googlelabs.com/ 6 http://bodybrowser.googlelabs.com/index.html 3 http://bodybrowser.googlelabs.com/body.html#ui=1,0&opa=s:1,m:1,sk:1,c:1,o:1,ci:1,n:1&sel=&lab=&nav=1.57,120,160 3 http://bodybrowser.googlelabs.com/body.html# 2 http://bodybrowser.googlelabs.com/body.html 1 http://www.mushroomtube.com/cgi-bin/atx/out.cgi?s=95&c=1&l=sid:21;iid:1;gid:2150379;kwid:5752;pos:1&u=http://book-mark.net/videos/1598/perfect-gf-body.html?utm_source=awn&utm_medium=cpc&utm_campaign=tube 1 http://www.google.com.tr/url?sa=t&source=web&cd=1&ved=0CCAQFjAA&url=http%3A%2F%2Fbodybrowser.googlelabs.com%2F&ei=XEwiTb-6EsKy8QO31Ox8&usg=AFQjCNEr0PPdvzS38zcH1w3HF_SVBgA4xw&sig2=8OsJkSV6u3UM1Yc_ddjlTQ 1 http://webcache.googleusercontent.com/search?q=cache:Bw-esd8W-HQJ:bodybrowser.googlelabs.com/+body+browser+and+google+labs&cd=1&hl=en&ct=clnk&gl=us 1 http://bodybrowser.googlelabs.com/body.html#ui=0,0&opa=s:0,m:0,sk:0.27,c:0.27,o:0,ci:0.11,n:0.91&sel=&lab=&nav=-1.56,100.57,27.16 we might have also been tickling this bug on 10 http://www.html5test.com/ and http://html5test.com/ and the support site 32 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/firefox-help 23 http://support.mozilla.com/1/firefox/4.0b8/WINNT/ru/plugin-crashed 18 http://support.mozilla.com/ 17 http://support.mozilla.com/1/firefox/4.0b8/WINNT/de/firefox-help 12 https://support.mozilla.com/en-US/kb/Get+help+with+Firefox+4+Beta 12 https://services.mozilla.com/sync/help/easy-setup 11 http://www.mozilla.com/en-US/firefox/help/ 8 http://support.mozilla.com/hr/questions/705278 7 https://wnu.com/secure/fpost.cgi 2 http://support.mozilla.com/kb/Search+bar 2 http://support.mozilla.com/it/kb/Ripristino%20della%20sessione 2 http://support.mozilla.com/it/kb/Eliminare%20la%20cronologia%20della%20barra%20degli%20indirizzi 2 http://support.mozilla.com/hu/kb/Pop-up%20blocker 2 http://support.mozilla.com/en-US/kb/Firefox%20is%20slow 2 http://support.mozilla.com/en-US/kb/Bookmarks 2 http://support.mozilla.com/en-US/kb/?S100719_support&WT.mc_ev=click 2 http://support.mozilla.com/en-US/home/?redirectlocale=en-US&redirectslug=Windows+start+page 2 http://support.mozilla.com/en-US/home/?as=u 2 http://support.mozilla.com/en-US/forum/1/711085?forumId=1&comments_threshold=0&comments_parentId=711085&comments_offset=20&comments_per_page=20&thread_style=commentStyle_plain 2 http://support.mozilla.com/de/kb/Zugriff%20auf%20FTP-Server 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/pl/ieusers 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/nb-NO/firefox-help 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/hu/ieusers 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/private-browsing 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/prefs-weave 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/prefs-languages 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/prefs-connection-settings 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/places-locked 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-US/ 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/en-GB/firefox-help 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/de/prefs-clear-private-data 2 http://support.mozilla.com/1/firefox/4.0b8/WINNT/cs/firefox-help 2 http://support.mozilla.com/1/firefox/4.0b7/WINNT/uk/ieusers 2 http://support.mozilla.com/1/firefox/4.0b7/WINNT/ru/firefox-help 2 http://support.mozilla.com/1/firefox/4.0b7/WINNT/pl/firefox-help
Flags: in-litmus?
I was just able to repro a crash on the body browser site using the latest nightly, but I get the stack in Bug 594357: http://crash-stats.mozilla.com/report/index/bp-409df259-2e62-49d0-af99-3671c2110106
(In reply to comment #18) > http://hg.mozilla.org/mozilla-central/rev/efad321b7a2e > > can you guys check if the problem is fixed in tomorrow's nightly build? Nightly build 2011-01-07 fixed it for me. all url's i had problems with and reported here work.
(In reply to comment #21) > I was just able to repro a crash on the body browser site using the latest > nightly, but I get the stack in Bug 594357: > > http://crash-stats.mozilla.com/report/index/bp-409df259-2e62-49d0-af99-3671c2110106 OK, this is not really conclusive: all this tells us is that the Intel OpenGL driver is crashy, which we already knew, and which we plan to work around by using ANGLE for rendering instead. You can already use ANGLE for rendering, you just need to install the DirectX runtime and it will be picked up automatically. We're working on redistributing the required dll (d3dx9_42.dll)
(In reply to comment #22) > (In reply to comment #18) > > http://hg.mozilla.org/mozilla-central/rev/efad321b7a2e > > > > can you guys check if the problem is fixed in tomorrow's nightly build? > > Nightly build 2011-01-07 fixed it for me. all url's i had problems with and > reported here work. Great, let's mark this bug as fixed.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Crash Signature: [@ @0x0 | mozilla::gl::GLContext::MarkDestroyed() ]
Assignee: nobody → bjacob
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: