Unable to reproduce the issue on Linux Ubuntu 14.04 using chrome version 50.0.2661.75.Entered the 3 commands in terminal.
Getting command not found after entering the "# HOME=/tmp chromium /tmp/Blendr\ —\ Encounters.html".
Please find the attached screen shot and confirm anything missed here.

Could you please provide us the crash id from chrome://crashes to triage the issue further.

Thanks,

Deleted: 604165.png 336 KB

	604165.png 336 KB View Download

The # just indicates I was using root's shell.
https://en.wikibooks.org/wiki/Guide_to_Unix/Explanations/Shell_Prompt#Root_shell_prompt

You are not supposed to type it back in.
You are supposed to remove it from the beginning of each line.

Then I changed (su) to user "nobody", only to show I was using a
pristine environment.

You don't have to do that.

So please try again with:

1. Save the attachment to r.cpio.gz
2. Do
r.cpio.gz | cpio -idvm
chromium /tmp/Blendr\ —\ Encounters.html

Thanks.

Thank you for providing more feedback. Adding requester "kavvaru@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://sites.google.com/a/chromium.org/dev/issue-tracking/autotriage - Your friendly Sheriffbot

Received signal 11 SEGV_MAPERR 0000002e6800
#0 0x0000808d062c <unknown>
#1 0x0000808d0a88 <unknown>
#2 0x0000b77ced9c ([vdso]+0xd9b)
#3 0x000083efaa53 <unknown>
#4 0x000083efab69 <unknown>
#5 0x000084e9dbd9 <unknown>
#6 0x000084e8830f <unknown>
#7 0x000084e8858d <unknown>
#8 0x000084e84f50 <unknown>
#9 0x00008093d1cd <unknown>
#10 0x0000808efaa6 <unknown>
#11 0x0000808f05b2 <unknown>
#12 0x0000808f08c1 <unknown>
#13 0x0000808f23b9 <unknown>
#14 0x0000808ef2ea <unknown>
#15 0x00008090833f <unknown>
#16 0x0000808eec72 <unknown>
#17 0x000080921bdb <unknown>
#18 0x00008091da34 <unknown>
#19 0x0000b60e528a start_thread
#20 0x0000b60114fe clone
  gs: 00000033  fs: 00000000  es: 0000007b  ds: 0000007b
 edi: 8633c836 esi: 00000000 ebp: 002e6800 esp: a91fda24
 ebx: 88d325c0 edx: 00000000 ecx: 002e6800 eax: 00000000
 trp: 0000000e err: 00000004  ip: 83efaa53  cs: 00000073
 efl: 00010246 usp: a91fda24  ss: 0000007b
[end of stack trace]
[4112:4139:0423/181135:ERROR:zygote_host_impl_linux.cc(162)] Failed to adjust OOM score of renderer with pid 4350: Permission denied

Seen on https://www.facebook.com/profile.php?id=100005295078357
but you will probably get different results.

And, browsing https://www.youtube.com/watch?v=_I28X0nqYMs gives the aw snap page, and the attachered "er" (STDERR) error file,

Deleted: er 6.0 KB

er 6.0 KB View Download

Unable to reproduce the crash upon navigating to the above Youtube URL mentioned in # 6.

Please also provide the Linux OS details that you are using.

I can't reproduce it today with that YouTube URL either.

All I know is recently I have had tons of Aw Snaps on Debian.
Today I am using version

chromium:
  Installed: 50.0.2661.94-1
  Candidate: 50.0.2661.94-1
  Version table:
 *** 50.0.2661.94-1 500
        500 http://free.nchc.org.tw/debian unstable/main i386 Packages
        100 /var/lib/dpkg/status

but I expect the Aw Snaps to continue.

Thank you for providing more feedback. Adding requester "pucchakayala@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Hi

Same issue here: snaps with SEGV_MAPERR, but on all pages, all the time - even chrome:// ones (so no chrome://crashes for you). Sometimes I get lucky for a few seconds and the page sticks around for a while, but it never lasts and most pages crash instantly.

Chromium 49.something used to work well, but 50 onwards don't. I'm on 51.0.2704.63 now.

Tried disabling all extensions, moving .config/chromium and .cache/chromium away to get a clean environment, downgrading kernel (to a version that was a known-good combination back in the times of 49). To no avail.

I'm annoyed about the stack trace. Even with virtually all debug infos in my system installed, we always see so many unknown symbols...

Received signal 11 SEGV_MAPERR 000000000008
#0 0x561e074b247e <unknown>
#1 0x561e074b2869 <unknown>
#2 0x7fc495c53de0 <unknown>
#3 0x561e081f3830 <unknown>
#4 0x561e081f3a74 <unknown>
#5 0x561e081f5590 <unknown>
#6 0x561e084f08e6 <unknown>
#7 0x561e0751933f <unknown>
#8 0x561e0bd35dff <unknown>
#9 0x561e0bd36417 <unknown>
#10 0x561e0bd33c4a <unknown>
#11 0x561e0751933f <unknown>
#12 0x561e074ced6e <unknown>
#13 0x561e074cf8bd <unknown>
#14 0x561e074d082c <unknown>
#15 0x561e074d14e5 <unknown>
#16 0x561e074e693a <unknown>
#17 0x561e074ce125 <unknown>
#18 0x561e0a784b48 <unknown>
#19 0x561e0747fada <unknown>
#20 0x561e07480054 <unknown>
#21 0x561e0747f18c <unknown>
#22 0x561e0701effa ChromeMain
#23 0x7fc4958c2761 __libc_start_main
#24 0x561e0701eeb9 _start
  r8: 00000000ffffffff  r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000246
 r12: 0000561e0e543a0b r13: 0000561e0e583e1b r14: 412f9e1593f7ceda r15: 00007fff25d7c1a0
  di: 000031da39c73be0  si: 000031da39be48c0  bp: 000031da39c09000  bx: 000031da39c43090
  dx: 000031da39c73c98  ax: 0000000000000000  cx: 00001812eb000000  sp: 00007fff25d7bf10
  ip: 0000561e081f3830 efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000006
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
[end of stack trace]


...but given that the top address seems to be in the same range as ChromeMain, I'm betting the crash is inside some bundled static library in chromium. If anybody knows what changed from 49 to 50 in that front, I'll appreciate any infos.

Cheers,
Arthur

Sure enough, /proc/<pid>/maps says the innermost place where the segv happens is inside pages of /opt/chromium/chrome:

561e06577000-561e0dea8000 r-xp 00000000 08:01 11721146                   /opt/chromium/chrome
561e0e0a8000-561e0e510000 r--p 07931000 08:01 11721146                   /opt/chromium/chrome
561e0e510000-561e0e53f000 rw-p 07d99000 08:01 11721146                   /opt/chromium/chrome

So I'm excluding external factors at this moment.

Looking at the config flags during compilation, I suspect that the -Duse_system_*=0 mean to use the bundled options. The only ones that my distro lets chromium use internally are:

-Duse_system_ffmpeg=0
-Duse_system_icu=0
-Duse_system_libusb=0
-Duse_system_libvpx=0
-Duse_system_protobuf=0
-Duse_system_sqlite=0
-Duse_system_v8=0
-Duse_system_zlib=0

I hope it helps you guys pinpoint the culprit, but I'll keep investigating as well.

Cheers,
Arthur

Turns out I'm having trouble getting the debug symbols to show in the stack trace - that's why there were so many <unknown> before. Chromium is now compiled with symbols embedded instead of external.

Received signal 11 SEGV_MAPERR 000000000008
#0 0x5608873d847e base::debug::StackTrace::StackTrace()
#1 0x5608873d8869 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f58e1914de0 <unknown>
#3 0x560888119830 v8::internal::IncrementalMarking::ActivateIncrementalWriteBarrier()
#4 0x560888119a74 v8::internal::IncrementalMarking::StartMarking()
#5 0x56088811b590 v8::internal::IncrementalMarking::Start()
#6 0x56088810fa54 v8::internal::Heap::CollectGarbage()
#7 0x5608880d7552 v8::internal::Factory::NewFillerObject()
#8 0x5608884642ca v8::internal::Runtime_AllocateInTargetSpace()
#9 0x1f3c3a5079a7 <unknown>
  r8: 00000000ffffffff  r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000246
 r12: 000056088e469a13 r13: 000056088e4a9e1b r14: 0000000000000000 r15: 0000000000000000
  di: 0000038f37cd8be0  si: 0000038f37c3e8c0  bp: 0000038f37d22840  bx: 0000038f37c9a090
  dx: 0000038f37cd8c98  ax: 0000000000000000  cx: 00003fa08c100000  sp: 00007fff02cfcb40
  ip: 0000560888119830 efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000006
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
[end of stack trace]

Searching for #3, I found this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68853

Which suggests that chromium should probably consider adding -fno-delete-null-pointer-checks to its default compiler flags from now on.

I will add it locally and report back soon.

Cheers,
Arthur

Hi again.

That's affirmative. Adding -fno-delete-null-pointer-checks to chromium compilation under GCC>=6 solves the issue for me. Either that or making V8's garbage collector stop depending on undefined behaviour. ;-)

Hope it helps you guys.

Cheers,
Arthur

Cleaning up "Needs-Review" label as we are not using this label for triage anymore. Ref bug for this cleanup 684919

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

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