(No comment was entered for this change.)

Crash.txt 25.4 KB   View   Download

Browser crash? Regression within last couple of weeks. Can we narrow down the timeframe? Need more repeatable steps?

Browser Crash. I will try to get the exact steps to repro.

Following videos were all running , not sure if these are related.
http://shapeshed.com/examples/HTML5-video-element/
http://www.spreadfirefox.com/5years/de/
http://html5test.com/
http://www.somekindofpaper.info/articles/2009/07/07/html5-lt-videogt-demo.html
http://tinyvid.tv/
http://videos.mozilla.org/serv/mobile/firefox-mobile-large.ogv
http://double.co.nz/video_test/test2.html

well that was a waste of 90 minutes. I'm pretty sure this is a regression somewhere between  51362 and 55771 but I can't prove where. My attempts to repro while bisecting proved fruitless entirely, but I know that my waterfall builds at those two markers are good and bad.

This might have to do with flashblock/adblock, which i run on my normal profiles, but didn't make the effort to set up on each of the 7 bisect tries. I also tried incognito mode, didn't see any change.

back to QA for hopefully some more data.

Google Chrome : 6.0.495.0 dev

I have seen this crash several times on my personal mac. I don't have flashblock/adblock extensions installed.
Once it happened when I was closing the tab and once when I was navigating to a new url.

Crash ids:
1acffa0fbeac167b
13b6677b18f5e5a5

I think, I havn't seen this crash before 495.0 dev release.

This is  some thing started with 6.0.495.0 dev
I  am not able to repro it on Google Chrome	7.0.503.0 (Official Build 57033) , will check for similar crashes in next builds and update if there are still crashes on the same.

I'm removing release block dev since this is fixed in 503 which is likely the next release candidate.

7.0.503.0 (Official Build 57033) dev

This crash is not yet fixed in 503 dev.  Crash id: 49fb69232d0caac2

I added DrawAcceleratedSurfaceInstance only very recently.

Repro steps would be nice, but this is my bug to fix.

Line 835 in 495 is:

834 :	kbr@google	54923	com   plugin_container_manager_.Draw(
835 :	thakis@chr	55663	mium.org       context, plugin_handle, GetRenderWidgetHost()->is_gpu_rendering_active());

I bet GetRenderWidgetHost() returns 0.

The good thing is that this parameter isn't even used for anything, so I removed it in http://codereview.chromium.org/3132038 / r57135 yesterday. Which means this crash should go away once r57135 comes to the dev channel.

(No comment was entered for this change.)

As I said, I think this is fixed.

Verified label updated by AutoAllocator, contact AmolK or KrisR for details

(No comment was entered for this change.)

 Issue 54000  has been merged into this issue.

(No comment was entered for this change.)

Marking as verified. 
Haven't seen this crash in 7.0.513.0 (Official Build 58304) dev.

(No comment was entered for this change.)

Reopening, because 517 has:
http://crash/reportdetail?reportid=ee6c8eca06f42ad6
http://crash/reportdetail?reportid=cc8fb8963036a4ab
http://crash/reportdetail?reportid=cbef0b96916def66

[These are three separate clusters of crashes, not three crashes from the same cluster.]

Possibly related:
http://crash/reportdetail?reportid=c4cec0fe022decdf


Thread 18 *CRASHED* ( EXC_BREAKPOINT / EXC_I386_BPT @ 0x008183c4 )

0x008183c4	 [Google Chrome Framework	 - debug_util_posix.cc:262]	DebugUtil::BreakDebugger
0x0082b1d3	 [Google Chrome Framework	 - logging.cc:596]	logging::LogMessage::~LogMessage
0x0057ae97	 [Google Chrome Framework	 - accelerated_surface_container_manager_mac.cc:91]	AcceleratedSurfaceContainerManagerMac::Draw
0x005958b4	 [Google Chrome Framework	 - render_widget_host_view_mac.mm:245]	-[AcceleratedPluginView drawView]
0x005925da	 [Google Chrome Framework	 - render_widget_host_view_mac.mm:180]	-[AcceleratedPluginView getFrameForTime:]
0x95e79bf3	 [CoreVideo	 + 0x00003bf3]	CVDisplayLink::performIO(CVTimeStamp*)
0x95e78827	 [CoreVideo	 + 0x00002827]	CVDisplayLink::runIOThread()
0x95e78455	 [CoreVideo	 + 0x00002455]	startIOThread(void*)
0x9856281c	 [libSystem.B.dylib	 + 0x0002e81c]	_pthread_start
0x985626a1	 [libSystem.B.dylib	 + 0x0002e6a1]	thread_start

I think the crashes from comments 19 and 20 have a different cause then this bug was originally about (not that it matters much :-P).

(No comment was entered for this change.)

hey Nico, do you think you can get this fixed by Friday:?

I'll try.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59684

------------------------------------------------------------------------
r59684 | thakis@chromium.org | Thu Sep 16 12:18:46 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=59684&r2=59683&pathrev=59684
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=59684&r2=59683&pathrev=59684

Mac: Fix concurrent access on a non-threadsafe data structure.

Also remove a call to cocoa from the non-ui thread.

DrawAcceleratedSurfaceInstance is called on the display link thread. plugin_views_ can be written to from the main thread. Since the map is only used to get the view's size, pass in the size right away.

There's another problem like this in plugin_container_manager_, which also has a map that is accessed from two threads. I will address this in a follow-up CL.

BUG=52491
TEST=none

Review URL: http://codereview.chromium.org/3431011
------------------------------------------------------------------------

http://codereview.chromium.org/3391011/show

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59890

------------------------------------------------------------------------
r59890 | thakis@chromium.org | Fri Sep 17 18:30:05 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.cc?r1=59890&r2=59889&pathrev=59890
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.h?r1=59890&r2=59889&pathrev=59890

Map: Guard concurrent accesses to a std::map by a lock in drawing code.

Both UI thread and displaylink thread always take the CG lock before taking this new lock, hence this shouldn't deadlock (the UI thread sometimes only takes and releases the new lock without attempting to take the CG lock).

BUG=52491
TEST=no more crashes in DrawAcceleratedSurfaceInstace

Review URL: http://codereview.chromium.org/3391011
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59894

------------------------------------------------------------------------
r59894 | thakis@chromium.org | Fri Sep 17 21:24:10 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/517/src/chrome/browser/renderer_host/render_widget_host_view_mac.h?r1=59894&r2=59893&pathrev=59894
 M http://src.chromium.org/viewvc/chrome/branches/517/src/chrome/browser/renderer_host/render_widget_host_view_mac.mm?r1=59894&r2=59893&pathrev=59894

Merge 59684 - Mac: Fix concurrent access on a non-threadsafe data structure.

Also remove a call to cocoa from the non-ui thread.

DrawAcceleratedSurfaceInstance is called on the display link thread. plugin_views_ can be written to from the main thread. Since the map is only used to get the view's size, pass in the size right away.

There's another problem like this in plugin_container_manager_, which also has a map that is accessed from two threads. I will address this in a follow-up CL.

BUG=52491
TEST=none

Review URL: http://codereview.chromium.org/3431011

TBR=thakis@chromium.org
Review URL: http://codereview.chromium.org/3437008
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59896

------------------------------------------------------------------------
r59896 | thakis@chromium.org | Fri Sep 17 21:28:20 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/517/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.h?r1=59896&r2=59895&pathrev=59896
 M http://src.chromium.org/viewvc/chrome/branches/517/src/chrome/browser/renderer_host/accelerated_surface_container_manager_mac.cc?r1=59896&r2=59895&pathrev=59896

Merge 59890 - Map: Guard concurrent accesses to a std::map by a lock in drawing code.

Both UI thread and displaylink thread always take the CG lock before taking this new lock, hence this shouldn't deadlock (the UI thread sometimes only takes and releases the new lock without attempting to take the CG lock).

BUG=52491
TEST=no more crashes in DrawAcceleratedSurfaceInstace

Review URL: http://codereview.chromium.org/3391011

TBR=thakis@chromium.org
Review URL: http://codereview.chromium.org/3463005
------------------------------------------------------------------------

(No comment was entered for this change.)

Haven't seen any crashes with this stack trace recently.

Platform:
  Hostname: testings-mac-mini-3.local
  Mac OS X Version 10.6.4 (Build 10F569)
  Processor: 4 Intel 2.66 GHz
  RAM: 2048 MB

Chrome:
  Chrome version: 6.0.495.0 r56152  <<<Release/Debug>>>
  QuickTime Player: 7.6.6
  QuickTime PlayerX: 114


Thread 37 *CRASHED* ( EXC_BAD_ACCESS / KERN_PROTECTION_FAILURE @ 0x0000003a )

0x0056736b	 [Google Chrome Framework	 - render_widget_host_view_mac.mm:835]	RenderWidgetHostViewMac::DrawAcceleratedSurfaceInstance
0x005673e4	 [Google Chrome Framework	 - render_widget_host_view_mac.mm:227]	-[AcceleratedPluginView drawView]
0x0056431a	 [Google Chrome Framework	 - render_widget_host_view_mac.mm:170]	-[AcceleratedPluginView getFrameForTime:]
0x957e7fc7	 [CoreVideo	 + 0x00002fc7]	CVDisplayLink::performIO(CVTimeStamp*)
0x957e6bfb	 [CoreVideo	 + 0x00001bfb]	CVDisplayLink::runIOThread()
0x957e6829	 [CoreVideo	 + 0x00001829]	startIOThread(void*)
0x990c581c	 [libSystem.B.dylib	 + 0x0002e81c]	_pthread_start
0x990c56a1	 [libSystem.B.dylib	 + 0x0002e6a1]	thread_start

<b>What steps will reproduce the problem?</b>

There are no consistent steps and could not be repeatable 
When it crashed I was running some HTML5 video tag testes

Crash ID :  e77eeaf706f808e5

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)