Repeatable crash with WebGL on Linux
Reported by
vangelis...@tri.global,
Aug 9
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Steps to reproduce the problem: Navigate to: https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/?src=Custom%20DataSource.html What is the expected behavior? What went wrong? The page leads to an Aw Snap renderer crash. It reproduces on multiple workstations on Linux but not on other OS's. We get similar crashes with an internal app using Cesium. A couple of crash IDs: Uploaded Crash Report ID 6eb98cc43c505501 (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 9, 2018 at 9:31:16 AM Uploaded Crash Report ID da58f4708b218601 (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 9, 2018 at 9:33:55 AM Did this work before? N/A Chrome version: 67.0.3396.87 Channel: stable OS Version: 16.04 Flash Version:
,
Aug 9
Unable to repro this with Chrome 68.0.3440.106 on Linux. Looking at report 6eb98cc43c505501 the expected upload bytes was ~1KiB, which suggests that there was no minidump for Breakpad to even try to upload. I was able to trivially repro issue 680342, and identified that the repro sites all created huge numbers of WebWorkers, and then ran WASM in them; we identified that the rlimit meant that couldn't possibly work. I don't know if anyone identified why that prevents us generating a minidump, though - adding mark@ in case he has input.
,
Aug 9
I don’t know, but we’re this --> <-- close to replacing the Breakpad client with Crashpad on Linux platforms. It’s way more out-of-process and will hopefully help with things like this. +ivanpe in case he knows what might cause no-minidump-upload as in go/crash/6eb98cc43c505501.
,
Aug 9
Good to hear that Breakpad is on its way out. Is there any way for a customer to manually enable Crashpad in Chrome Stable on Linux as an alternative? Perhaps they could collect a crash using it.
,
Aug 9
It’s not yet ready. We’re working down the integration change, there are a few more small pieces to pick off and land.
,
Aug 10
I see nothing interesting about that report. We just didn't get any files with it.
I0809 09:31:16.063906 591468 unnamed collector.cc:1449 Report request header received. Report=6eb98cc43c505501, product=, version=, clientid=
I0809 09:31:16.118555 591400 unnamed collector.cc:1093 Full report request received and parsed. Report=6eb98cc43c505501, product=Chrome_Linux, version=67.0.3396.87
I0809 09:31:16.126253 591400 unnamed collector.cc:726 Stored report=6eb98cc43c505501, product=Chrome_Linux, version=67.0.3396.87
ReportID: "6eb98cc43c505501"
ClientID: "AECnTLnhId0EAm8EF+GEbD7WXDZCVLccJA=="
ReportTime: 1533832276118
ProcessUptime: 2423319
Product {
Name: "Chrome_Linux"
Version: "67.0.3396.87"
}
ProductData {
Key: "pid"
Value: "3844"
}
ProductData {
Key: "ptype"
Value: "renderer"
}
...
ProcessingFailed: true
upload_info {
upload_bytes: 6288
expected_upload_bytes: 1446
}
stable_signature: "NoFileToProcess"
...
,
Aug 10
Good news! I updated to the latest chrome stable build (68.0.3440.106) and have so far NOT been able to reproduce the issue with either the url I provided originally or our internal application. I apologize for sounding the alarm before trying an update. The crash had been plaguing for us since Chrome 64 and I assumed it was still a problem. Looks like something fixed it recently. Please feel free to close this issue. Thank you all for the quick response and for keeping Chrome rocking!
,
Aug 10
vangelis.kokkevis@ Thanks for the update. As per comment #7, closing the issue. Please feel free to raise a new bug if any issues are observed on the latest Chrome builds. Thanks..
,
Aug 10
Relieved that the update fixed things! |
||||
►
Sign in to add a comment |
||||
Comment 1 by kbr@chromium.org
, Aug 9Cc: w...@chromium.org
Components: -Blink Internals>CrashReporting Blink>WebGL
Labels: -Pri-2 Pri-1
Owner: kbr@chromium.org