New issue
Advanced search Search tips

Issue 820739 link

Starred by 1 user

Issue metadata

Status: Archived
Owner: ----
Closed: Sep 13
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 705916



Sign in to add a comment

Remote controlled Chromium crashes with EXC_BAD_ACCESS when closed manually

Reported by mekishiz...@gmail.com, Mar 10 2018

Issue description

Chrome Version: 66.0.3347.0 (3347.0)

What steps will reproduce the problem?
(1) Install the latest version of Puppeteer (1.1.1 as of right now; downloads Chromium r536395) (https://github.com/GoogleChrome/puppeteer)
(2) Run the following script:

const puppeteer = require('puppeteer');

async function main() {
  const browser = await puppeteer.launch({
    headless: false
  });

  // <snip>
}

main().then(console.log).catch(console.log);


(3) Once a new Chromium window is opened, close it and wait for a few seconds. The Chromium process crashes with the following:

Process:               Chromium [71604]
Path:                  /private/tmp/*/Chromium.app/Contents/MacOS/Chromium
Identifier:            org.chromium.Chromium
Version:               66.0.3347.0 (3347.0)
Code Type:             X86-64 (Native)
Parent Process:        node [71603]
Responsible:           iTerm2 [662]
User ID:               501

Date/Time:             2018-03-10 18:23:26.365 +0100
OS Version:            Mac OS X 10.13.3 (17D102)
Report Version:        12
Bridge OS Version:     3.0 (14Y661)

Time Awake Since Boot: 670000 seconds
Time Since Wake:       6700 seconds

System Integrity Protection: enabled

Crashed Thread:        30  Chrome_DevToolsHandlerThread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000028

VM Regions Near 0x28:
--> 
    __TEXT                 000000010ec50000-000000010ec51000 [    4K] r-x/rwx SM=COW  /tmp/*/Chromium.app/Contents/MacOS/Chromium

Thread 30 Crashed:: Chrome_DevToolsHandlerThread
0   org.chromium.Chromium.framework	0x0000000112a4e184 0x10ec7a000 + 64831876
1   org.chromium.Chromium.framework	0x0000000110a8be0c 0x10ec7a000 + 31530508
2   org.chromium.Chromium.framework	0x0000000110ab1cc4 0x10ec7a000 + 31685828
3   org.chromium.Chromium.framework	0x0000000110ab21b8 0x10ec7a000 + 31687096
4   org.chromium.Chromium.framework	0x0000000110ab33d5 0x10ec7a000 + 31691733
5   org.chromium.Chromium.framework	0x0000000110ad8b15 0x10ec7a000 + 31845141
6   org.chromium.Chromium.framework	0x0000000110b0aaac 0x10ec7a000 + 32049836
7   org.chromium.Chromium.framework	0x0000000110b05d87 0x10ec7a000 + 32030087
8   libsystem_pthread.dylib       	0x00007fff767286c1 _pthread_body + 340
9   libsystem_pthread.dylib       	0x00007fff7672856d _pthread_start + 377
10  libsystem_pthread.dylib       	0x00007fff76727c5d thread_start + 13


What is the expected result?

I'm not sure what's the contract between the remotely controlled instance and the one who controls it but it certainly should not crash.
 
> Once a new Chromium window is opened, close it and wait for a few seconds.

Actually, not just the window, quit the instance (⌘Q).
Components: UI
Labels: Needs-Triage-M66
Components: Internals>Headless
Labels: Triaged-ET TE-NeedsTriageHelp
The issue seems to be out of TE-scope as it is related to Puppeteer tool for chrome headless. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!
Status: Archived (was: Unconfirmed)
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!
I just tried it with Puppeteer 1.8.0 and the problem seems to have gone away somewhere between the versions. Feel free to mark this as closed.

Sign in to add a comment