New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 69195 link

Starred by 4 users

Issue metadata

Status: Verified
Email to this user bounced
Closed: Jan 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

playing Z-Type causes crash

Reported by, Jan 11 2011

Issue description

Chrome Version       : 8.0.552.215 (Developer Build 0)
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 5:
Firefox 3.x:
IE 7/8:

Playing for 30-60 seconds causes a crash, at least in Linux. According to the thread below, Windows 7 and Mac at least do not have the same crash.
Labels: Restrict-View-SecurityTeam Security
I haven't been able to repro this with dev or canary. Some people are saying this crashes the browser though so I am adding security flags until we know what the issue is.
I've been playing Z-Type on Linux for quite some time today ;-)
It's been fine.

@daniel.wagner: please read our guidelines on reporting crash bugs:

It tells you how to get us some IDs relating to the crashes. In the event that we can't reproduce the issue, the crash reports at least might contain stack traces that give a hint as to where the problem lies.
Re: the instructions for Linux on that page:

- I don't see a 'Help make Google Chrome better by automatically sending usage statistics and crash reports to Google' option in 'Under the hood' -- perhaps because I'm using chromium, though I'm not sure
- grep client_id '.config/chromium/Local State' returns 1 (no matches)
- The console does not print a crash dump id. Here is all of the output from a session where I just loaded up Z-Type and played until it crashed (on wave 12):

sorghum:~% chromium
[5100:5100:318428763953:ERROR:base/] Couldn't open /home1/w/wagnerdm/.config/chromium/Default/Extensio
[5100:5100:318428763993:ERROR:chrome/browser/themes/] Failed to load theme data pack.
[5100:5100:318428764081:ERROR:chrome/browser/themes/] Could not load theme image
[5100:5100:318428764097:ERROR:chrome/browser/themes/] Could not load theme.
zsh: segmentation fault  chromium

The first four errors occurred more or less instantaneously -- before I visited the Z-Type page.
- I'll look into getting a backtrace shortly.

Unfortunately, Arch doesn't have a debug package. I did update to the latest version available in the repo (8.0.552.224 (Developer Build 0)) and still observe the problem. I can include a core dump, if that would be helpful; if there are clear and fairly simple instructions for building a debug build myself, I'm willing to give that a shot, too.
@daniel.wagner: thanks for your help on this. Yep, only the official Google builds of Chrome log crash reports.
Not to worry, I've had a look around and I think I've found some examples -- it very much appears to be an audio-related thing:


Thread 9 *CRASHED* ( EXCEPTION_ACCESS_VIOLATION_WRITE @ 0xffffffffef46307f )

0x765f1398	 [kernel32.dll	 + 0x00011398]	InterlockedExchangeAdd
0x58c2e3a5	 [chrome.dll	 -]	base::subtle::RefCountedThreadSafeBase::Release()
0x58c8389e	 [chrome.dll	 - ref_counted.h:141]	base::RefCountedThreadSafe<LoginHandler,base::DefaultRefCountedThreadSafeTraits<LoginHandler> >::Release()
0x5941bd36	 [chrome.dll	 - list:840]	std::list<scoped_refptr<media::Buffer>,std::allocator<scoped_refptr<media::Buffer> > >::clear()
0x5941b7bf	 [chrome.dll	 -]	media::SeekableBuffer::~SeekableBuffer()
0x59413ad9	 [chrome.dll	 -]	media::AudioOutputController::~AudioOutputController()
0x59413aaf	 [chrome.dll	 + 0x008b3aaf]	media::AudioOutputController::`scalar deleting destructor'(unsigned int)
0x58e6a08b	 [chrome.dll	 - ref_counted.h:142]	base::RefCountedThreadSafe<remoting::Tracer,base::DefaultRefCountedThreadSafeTraits<remoting::Tracer> >::Release()
0x58f41955	 [chrome.dll	 - scoped_ptr.h:75]	scoped_ptr<AudioRendererHost::AudioEntry>::~scoped_ptr<AudioRendererHost::AudioEntry>()
0x58f41621	 [chrome.dll	 -]	AudioRendererHost::DeleteEntry(AudioRendererHost::AudioEntry *)
0x5942150f	 [chrome.dll	 - task.h:330]	RunnableMethod<BrowsingDataAppCacheHelper,void ( BrowsingDataAppCacheHelper::*)(CallbackRunner<Tuple0> *),Tuple1<CallbackRunner<Tuple0> *> >::Run()
0x58c266ce	 [chrome.dll	 -]	MessageLoop::RunTask(Task *)
0x58c26755	 [chrome.dll	 -]	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &)
0x58c268ef	 [chrome.dll	 -]	MessageLoop::DoWork()

That's a Windows example; there's also the occasional Linux and Mac report with similar stack traces.

What we need now is a reliable way to quickly reproduce this :-/
@daniel.wagner: I wonder what it is about your system that makes it easy for you to reproduce this? I can play into the 40s with no crash.

What's your processor? Multi-core? What exact version of Linux? 32-bit or 64-bit?
Labels: -Area-Undefined Feature-Media
sorghum:~% uname -a
Linux sorghum 2.6.35-ARCH #1 SMP PREEMPT Wed Sep 29 08:45:18 CEST 2010 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

So, yup, multi-core, 64-bit, Linux 2.6.35.

I also noticed that it tends to play maybe one in four sound effects, and the ones that get through are somewhat stilted. It seemed unrelated; sorry for not including that in the report originally. Now that you think it is sound-related, it is perhaps relevant that I am using Alsa with a somewhat newly supported sound card (i.e. support came in 2.6.32 I think):

sorghum:~% lspci | grep -i audio
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
03:00.0 Audio device: Creative Labs X-Fi Titanium series [EMU20k2] (rev 03)

(All sound is going through the X-Fi.)
I managed to reproduce by playing a Linux debug build of Chromium for a long period of time. I hit this DCHECK() in SeekableBuffer::Append():

DCHECK_EQ(0u, forward_bytes_);

forward_bytes_ was 8192, but it's not clear if that was a "real" value or if we're operating on a deleted object.

I commented out the DCHECK() and did get a SIGSEGV, essentially identical to:

Thread 8 *CRASHED* ( SIGSEGV @ 0x00000010 )

0x7fc36df28d83	 [	 - ../../../../src/libstdc++-v3/src/]	std::_List_node_base::hook
0x0123241e	 [chrome	 - stl_list.h:1162]	media::SeekableBuffer::Append
0x01232585	 [chrome	 - media/base/]	media::SeekableBuffer::Append
0x01223ffd	 [chrome	 - media/audio/]	media::AudioOutputController::EnqueueData
0x00a19aed	 [chrome	 - chrome/browser/renderer_host/]	AudioRendererHost::OnNotifyPacketReady
0x00a194e5	 [chrome	 - ./ipc/ipc_message_utils.h:950]	AudioRendererHost::OnMessageReceived
0x00874e0c	 [chrome	 - chrome/browser/renderer_host/]	ResourceMessageFilter::OnMessageReceived

$19 = {current_buffer_ = {_M_node = 0x7fffdf4eb000}, 
  buffers_ = {<std::_List_base<scoped_refptr<media::Buffer>, std::allocator<scoped_refptr<media::Buffer> > >> = {
      _M_impl = {<std::allocator<std::_List_node<scoped_refptr<media::Buffer> > >> = {<__gnu_cxx::new_allocator<std::_List_node<scoped_refptr<media::Buffer> > >> = {<No data fields>}, <No data fields>}, _M_node = {_M_next = 0x0, 
          _M_prev = 0x7fff4c0ce8e0}}}, <No data fields>}, 
  current_buffer_offset_ = 140734468547904, backward_capacity_ = 0, 
  backward_bytes_ = 0, forward_capacity_ = 98304, forward_bytes_ = 73728, 
  current_time_ = {delta_ = -9223372036854775808}}
This is great - I can play all night and tell my wife I'm working!!
Labels: Mstone-9 ReleaseBlock-Stable SecSeverity-Critical
Status: Assigned
Andrew, who know this code best? Let's find someone to fix it for M9. Seems really nasty; flagging as such until we know otherwise.
Oho! I may have it... let me take this.
Project Member

Comment 13 by, Jan 12 2011

The following revision refers to this bug:

r71211 | | Wed Jan 12 11:20:01 PST 2011

Changed paths:

Use the lock when accessing the buffer object.

BUG= 69195 
TEST=play Z-Type for hours :)

Review URL:
Status: WillMerge
Although technically a browser-process corruption (which we have to rate critical), it's a very tricky timing-related issue and unlikely to actually be a real risk.
 Issue 69367  has been merged into this issue.
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Status: FixUnreleased
Merge to M9 with r71225
Also landed r71286 (M9: r71287) as a fix for another theoretical race.
Labels: Type-Security
Labels: SecImpacts-Stable
Batch update.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Labels: testcaseadded
Status: Verified
Project Member

Comment 23 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 24 by, Mar 10 2013

Labels: -Feature-Media -Mstone-9 -SecSeverity-Critical -Type-Security -SecImpacts-Stable Cr-Internals-Media M-9 Security-Impact-Stable Type-Bug-Security Security-Severity-Critical
Project Member

Comment 25 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 26 by, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 27 by, Mar 21 2013

Labels: -Security-Severity-Critical Security_Severity-Critical
Labels: reward-topanel
Project Member

Comment 29 by, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member

Comment 30 by, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Project Member

Comment 32 by, Jul 28

Labels: -Pri-2 Pri-0

Sign in to add a comment