When I visit most javascript heavy pages, like Stackoverflow.com, I get the "Aw Snap! Something went wrong displaying this page page ..." On that site I can get it to display if I refresh it anywhere from two to 10 times. My term shows this: Received signal 11 SEGV_MAPERR 000000000000 #0 0x00000089af67 <unknown> #1 0x000809b6c997 <unknown> #2 0x000809b6c1a8 <unknown> [end of stack trace] On FreeBSD 10.2 Chromium Version 46.0.2490.80 (64-bit) This has been going on for weeks but I thought I would see it already reported here. I don't find it so I'm surprised cause I've seen others talk about it on the forum.
Thanks for submitting this! This started happening after Chromium 42. A *lot* broke on 43 and it's much better now. Only problem seems to be the extremely frequent page crashes, which make it almost unusable. By the way, most development for the port seems to happen on Github. This is where I submitted the first report: https://github.com/gliaskos/freebsd-chromium/issues/14 I have a 1BTC bounty open for fixing it: https://github.com/gliaskos/freebsd-chromium/issues/40
I thought this was fixed two updates ago, cause it went away for me, but it's returned with a vengeance in this last update.
I'm so happy to hear I'm not the only one. I've been getting crashes on YouTube almost every time I load a video. Sometimes even the home page crashes when creating a new tab (duckduckgo in my case). Is there any hope to resolving this bug?
(In reply to Teran McKinney from comment #1) I managed to have gdb (from ports, newever version) attached to each spawned render process. The problem is in the render process, it just crashes for some reason. The version of www/chromium I debugged was 47.0.2526.106. I originally contacted GitHub user LeFroid (via email) about this, since somebody posted a bounty on this in GitHub, and LeFroid said he would look into it. I cannot post the data here, since the core dumps I extracted may contain private information and I don't want that to leak into the wider internet. But if a maintainer wants the core dumps, he/she can contact me and I will provide them.
(In reply to Teran McKinney from comment #1) Note! www/chromium was just updated to 48.0.2564.82 I recommend trying it out and see if you still get crashing tabs.
48.0.2564.82 is not better
(In reply to Arto Pekkanen from comment #5) While the frequency of crashes seems to have improved, it does still happen and did just a few minutes ago when visiting Stackoverflow.
48.0.2564.97 looks like it might be a winner. Have had it running for just on 24 hours now and not a single Aw Snap! With previous versions by now I typically would have seen a dozen or more. This latest one has either fixed it or reduced the frequency by a couple of orders of magnitude.
(In reply to Wayne Sierke from comment #8) Nope. I still get tab crashes every now and then. The issue has not been resolved as far as my system is concerned. I am waiting for a maintainer to contact me, I can provide core files (of the crashed render processes) if needed, but I am not going to make the core files if nobody is willing to start working on them.
(In reply to Arto Pekkanen from comment #9) Yes, unfortunately while my initial experience was much improved over earlier, recent versions, longer-term use has shown that the issue is very much still present. I do feel that it is somewhat improved, particularly on initial start, but over time it slowly deteriorates. I haven't encountered any pages that won't normally reload correctly straight away - with the exception of kickstarter, which currently crashes the browser altogether - but that I believe is a separate issue linked to something else that got upgraded. On the whole if "feels" like it's correlated to resource-usage (primarily memory). The page failures seem to occur more often the longer chromium is running and as its resource usage rises.
(In reply to Wayne Sierke from comment #10) I also noticed the same effects. In short, the longer Chromium is running, the more it uses memory. And at some point tabs start crashing. What I've learned by analyzing the core dumps with the debug build of chromium, a segfault happens somewhere in the stdc++ string template header. Now we would just need somebody proficient enough to figure out why this happens.
This problem also bothers me on random pages: the tab just freeze, the spinner in the tab list keeps rotating, but the page does not load anymore; it's like the loading was blocked. It can happen on any page, even when simply opening a new tab; sometimes, Chromium notes the frozen tab and asks me whether to kill it or wait for it, sometimes it doesn't. I'm using a Google account for sync and the synced data are encrypted using a custom password rather than with Google keys. I'm also using the packaged last version of Chromium under 11.0-RELEASE; the problem was already present under 10.3-RELEASE and the upgrade didn't help. Right now, Chromium runs verbose from a CLI, so I'll post any message I can link to hangs, but I already got some and nothing arises yet.
In the latest versions this issue is happening almost on every page. Even fairly simple pages, i.e. a personal project using a React table, is crashing randomly in about 50% of the time. See also this issue which seems to be reported later on a newer version (probably a duplicate): https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211202
*** Bug 211202 has been marked as a duplicate of this bug. ***
Can someone please reference https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212812 in the See Also section (unless the other ticket is duplicated against this one).
*** This bug has been marked as a duplicate of bug 212812 ***