Unable to reproduce the issue on Mac 10.12.2, Windows 10 and Ubuntu 14.04 using chrome reported version #56.0.2924.87 and latest canary #58.0.3019.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to url: http://august.com
2. The page loaded without any issues.

Reporter@ - Could you please check this issue on latest canary #58.0.3019.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Aha! In my /etc/pulse/daemon.conf, I have the following settings:

default-sample-format = s24-32le
default-sample-rate = 192000

If I comment them out (ie revert it back to default of 44100 and s16le), I can visit http://august.com without chromium crashing.

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I also noticed that in the byte counts given in the stack trace, 65473/98304 ~= 2/3

My chromium version is:
[ekce@anu ~]$ chromium --version
Chromium 62.0.3202.75 

I'm on Arch Linux as well.



I was having a very similar issue all day today except that mine kicked in after an update and seemed to happen while scrolling down on facebook (I think it must've been triggered by certain video files or something, no idea which though since it happened kind of randomly and too fast to really study). Unfortunately I wasted a lot of time on a false lead due to some extraneous error messages in journalctl (man chromium doesn't mention log levels at all and it doesn't spit out any errors to journalctl apparently either).

Anyway, in my case I had:
default-sample-rate = 96000
in /etc/pulse/daemon.conf (everything else was set to defaults including default-sample-format). However, after commenting out the default-sample-rate setting (so that it falls back to defaults of 44100) and restarting the pulseaudio server (via 'pulseaudio -k' and 'pulseaudio --start') seemed to fix the problem.


When running chromium from the command line and looking at error logs I got:
[ekce@anu ~]$ chromium --v=1 --log-level=0
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[94:146:1027/093901.620121:ERROR:adm_helpers.cc(62)] Failed to query stereo recording.
[20:157:1027/093902.365559:ERROR:adm_helpers.cc(62)] Failed to query stereo recording.
[12493:12493:1027/093911.985444:ERROR:desktop_window_tree_host_x11.cc(1880)] Not implemented reached in void views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState)
[12493:13923:1027/094021.674364:FATAL:pulse_output.cc(136)] Check failed: bytes_to_fill == static_cast<size_t>(params_.GetBytesPerBuffer()) (65472 vs. 65536)
#0 0x559f3117e7a6 <unknown>

Received signal 6
#0 0x559f3117e7a6 <unknown>
  r8: 0000000000000000  r9: 00007f9902b3cc70 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007f9902b3d130 r13: 000000000000009d r14: 00007f9902b3d120 r15: 00007f9902b3d140
  di: 0000000000000002  si: 00007f9902b3cc70  bp: 00007f9902b3d110  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f9939bb48a0  sp: 00007f9902b3cc70
  ip: 00007f9939bb48a0 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: fffffffe7ffbfedf cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.



Trying with extensions disabled also produced a crash just as quickly (though strangly I stopped getting the stereo recording errors):
[ekce@anu ~]$ chromium --v=1 --log-level=0 --disable-extensions
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[15341:15341:1027/094412.462494:ERROR:desktop_window_tree_host_x11.cc(1880)] Not implemented reached in void views::DesktopWindowTreeHostX11::MapWindow(ui::WindowShowState)
[15341:16566:1027/094457.773946:FATAL:pulse_output.cc(136)] Check failed: bytes_to_fill == static_cast<size_t>(params_.GetBytesPerBuffer()) (65472 vs. 65536)
#0 0x557594d8c7a6 <unknown>

Received signal 6
#0 0x557594d8c7a6 <unknown>
  r8: 0000000000000000  r9: 00007f8e43edbc70 r10: 0000000000000008 r11: 0000000000000246
 r12: 00007f8e43edc130 r13: 000000000000009d r14: 00007f8e43edc120 r15: 00007f8e43edc140
  di: 0000000000000002  si: 00007f8e43edbc70  bp: 00007f8e43edc110  bx: 0000000000000006
  dx: 0000000000000000  ax: 0000000000000000  cx: 00007f8e789b18a0  sp: 00007f8e43edbc70
  ip: 00007f8e789b18a0 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000000 msk: fffffffe7ffbfedf cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.


I made a crappy gdb backtrace (see attachment) but I don't really know what I'm doing and I'm pretty sure it's missing debug symbols even though the question marks are absent. I ought to be able to compile a version of chromium with debug symbols as well as some libraries but I'm hesitent to do it since I saw some comment online saying that compiling chromium with full debug symbols required 20 GB(?!) of space. I'm also not sure what packages I should recompile.


I did see at least a few other people on the net with a possibly related issue.
https://bugs.chromium.org/p/chromium/issues/detail?id=712012
https://bbs.archlinux.org/viewtopic.php?id=225820
https://www.alionet.org/showthread.php?33100-Probl%E8me-plantage-Chromium&p=291219

This other open issue sounds like it could be related maybe.
https://bugs.chromium.org/p/chromium/issues/detail?id=708917

Here's a bunch of people with what sounds to me almost identical to my situation.
https://www.reddit.com/r/chrome/comments/6786ng/facebook_freezes/

Let me know if there's any other way I can help debug this.

Deleted: trace.log 21.5 KB

trace.log 21.5 KB View Download

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!

Archiving old bugs that haven't been actively assigned in over 180 days.

If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!