I'm able to reproduce this crash on:
Google Chrome:  50.0.2661.91 (Official Build) (64-bit)
Platform: 7978.66.0 (Official Build) stable-channel samus

I see an error logged in file:///var/log/ui/ui.LATEST:
"Uncaught ReferenceError: options is not defined", source:  (1)

I wonder if there could be a Javascript error in the app?
The app's bottom bar says "Looking for new messages", then "Downloads complete. Still processing content."

Deleted: Screenshot 2016-05-03 at 10.51.48 AM.png 1.9 MB

	Screenshot 2016-05-03 at 10.51.48 AM.png 1.9 MB View Download

I will continue to look for a Javascript error in the app.

Because the Console log disappears when the app crashes I haven't been able to track anything down in the apps code as to what might be causing the crash.  It seems like it might be crashing at different places sometimes also.

The app works (does not crash) on Windows and Mac and on some Chromebooks.  But unfortunately the students have the Dell Chromebooks where the app crashes.

Thanks!

I was able to reproduce the crash on a Chromebook Pixel. Are you testing with identical versions of Chrome browser & Chrome OS?

Is there any logging or debug that can be done in the app? That status bar indicator might point to something in the code path that's causing the crash.

I have a HP Chromebook that does NOT crash...
Version 49.0.2623.112
Platform 7834.70.0 (Official Build) stable-channel daisy_spring
Firmware Google_Spring.3824.129.0

and I have a Acer Chrombook that does crash...
Version 49.0.2623.112 (64-bit)
Platform 7834.70.0 (Official Build) stable-channel parrot
Firmware Google_Parrot.2685.37.0

where the difference is the firmware.

Have you been able to see it crash it that same spot multiple times?

I am looking at the code after where it post that status to see if I can find a problem.

Is there anyway I can prevent the DevTools window from closing when the app crashes so I can see the Console log?

Thanks,
Keith

Interesting! I was able to run the app without crashing on an HP Chromebook 11 G1, which is an ARM-based Chromebook. The Chromebook Pixel and the Dell Chromebook 11 are both Intel-based.

Google Chrome	51.0.2704.29 (Official Build) dev (32-bit)
Platform	8172.16.0 (Official Build) dev-channel daisy_spring

Let me check on how else to debug this.

Deleted: Screenshot 2016-05-03 at 5.16.02 PM.png 51.7 KB

	Screenshot 2016-05-03 at 5.16.02 PM.png 51.7 KB View Download

I installed the Chrome Apps Developer Tools (https://chrome.google.com/webstore/detail/chrome-apps-extensions-de/ohmmkhmmmpcnpikjeljgnaoabkaalbgc?hl=en) to try to capture the error in a console. However, the crash still happens so quickly that the console disappears.

Upon uninstalling and reinstalling the app (without configuring it), I did find these errors in the console:

chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_gateway_discovery.js Failed to load resource: net::ERR_FILE_NOT_FOUND
chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_message_sync.js Failed to load resource: net::ERR_FILE_NOT_FOUND
chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_content_download.js Failed to load resource: net::ERR_FILE_NOT_FOUND
chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_content_processing.js Failed to load resource: net::ERR_FILE_NOT_FOUND
chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_message_cleanup.js Failed to load resource: net::ERR_FILE_NOT_FOUND
chrome-extension://mdbdfdpofdnnbneiomnmedknicifkfbk/js/workers/worker_reply_sender.js Failed to load resource: net::ERR_FILE_NOT_FOUND
background.js:57 installed

Deleted: app crash.gif 1.8 MB

	app crash.gif 1.8 MB View Download

Another screen capture of the app crashing after I click Submit on class details.

Deleted: app crash 1.gif 2.2 MB

	app crash 1.gif 2.2 MB View Download

I too had installed the Chrome Apps Developer Tools and ran into the same issue you did, crash happens so quickly that the console disappears.


The errors you see when you Inspect the background page are caused by the following lines at the top of the file mdbdfdpofdnnbneiomnmedknicifkfbk/app/js/controllers/controllers_shared_functions.js

var gatewayDiscoveryWorker = new Worker('js/workers/worker_gateway_discovery.js');
var messageSyncWorker = new Worker('js/workers/worker_message_sync.js');
var contentDownloadWorker = new Worker('js/workers/worker_content_download.js');
var contentProcessWorker = new Worker('js/workers/worker_content_processing.js');
var messageCleanupWorker = new Worker('js/workers/worker_message_cleanup.js');
var replySenderWorker = new Worker('js/workers/worker_reply_sender.js');

They should be changed to:

var gatewayDiscoveryWorker;
var messageSyncWorker;
var contentDownloadWorker;
var contentProcessWorker;
var messageCleanupWorker;
var replySenderWorker;

And those errors go away (the new is done later in the code).

Even after fix these errors the app still crashes.

I will clean up that code though, thanks for pointing it out.

@tvbstest1 - by any chance, does your app make use of Native Client?

No, our app does not make use of Native Client.

Both my Chromebooks updated this morning and there is no change in the crash behavior; the Acer (Intel-based) still crashes and the HP still does not crash.

HP Chromebook that still does NOT crash...
Version 50.0.2661.91
Platform 7978.66.0 (Official Build) stable-channel daisy_spring
Firmware Google_Spring.3824.129.0

Acer Chrombook that still does crash...
Version 50.0.2661.91 (64-bit)
Platform 7978.66.0 (Official Build) stable-channel parrot
Firmware Google_Parrot.2685.37.0

As this seems to be an issue on Intel-based Chromebooks, has anyone had any luck tracking down the issue?  Is there anything I can do on my end to help?

This is causing a major impact for our customer as most of the Chromebooks they have are Dells (Intel-based).

Thanks,
Keith

What is happening in between "Looking for new messages" and "All messages are now ready to be read"? The former status is shown when I launch the app, the latter is what it stays on when it doesn't crash on an ARM-based Chromebook. Maybe you can use the Chrome Apps Developer Tools to set a breakpoint and then step through the code?

OK I set an initial breakpoint at line 16 of app/js/worker/worker_message_sync.js and went from there.  Added a breakpoint at line 88 of that same file and it crashes after that.  Stepping into that function takes you to line 196 of the same file.  After stepping through that function (syncComplete) the crash happens.  But not every time, sometimes you have to step through the code several times before the crash happens.

Note the breakpoint at line 88 is on a call to a function 'syncComplete'.  Depending on the state of your app it might actually call 'syncComplete' from line 133 or line 153.  Never the less the crash happens after the 'syncComplete' call.

OK, the 'syncComplete' is just kicking off another web worker so I've been stepping through the initContentDownloadWorker function at line 222 of app/js/controllers/controllers_shared_functions.js which lead me to line 171 of worker_content_download.js in the function unzipDownloadedFile.  Most of the time executing line 171 causes the crash but sometimes its the next line (173) where it crashes.  A few times it has gotten past both of those lines and then crashes on line 193.  
The common thread on all these lines of code where the app crashes on are that they are accessing the FileSystem.

It's definitely related to the download / file save process. When I disconnect Wi-Fi, the app stays up and running. When I re-enable Wi-Fi and click Refresh, it crashes.

Can you provide a few lines of code where the crash seems to be happening so that we can isolate it to the specific Javascript / Chrome API function call? 

Deleted: Screenshot 2016-05-06 at 10.26.21 AM.png 622 KB

	Screenshot 2016-05-06 at 10.26.21 AM.png 622 KB View Download

        var messageGroupDirSync = syncFs.root.getDirectory(message.messageGroupId, {create: true});
is the line 171 of app/js/workers/worker_content_download.js that it often crashes on.

syncFs is intialize on line 54 of the file like this:
    var syncFs = getSynchronousFileSystem(self);

getSynchronousFileSystem is defined in app/js/utils.js at line 288 as:

function getSynchronousFileSystem(self) {
    self.requestFileSystemSync = self.webkitRequestFileSystemSync ||
        self.requestFileSystemSync;
    return self.requestFileSystemSync(PERSISTENT, 1024*1024);
}

Reproduced the issue and captured logs. Attaching logs for debug.

Google Chrome	50.0.2661.91 (Official Build) (64-bit)
Platform	7978.66.0 (Official Build) stable-channel samus

Deleted: debug-logs_20160506-172014.tgz 3.0 MB

debug-logs_20160506-172014.tgz 3.0 MB Download

Hi Scott - can you help repro this or route to the right test / eng team?  This is hitting us in the field.

This looks similar in some ways to bug 592124 -crash deep in blink on string stuff but only on some machines.

From issue 592124 (Crash when accessing HTML5 synchronous file system api in a worker thread), there is an isolated repro:

for (var i = 0; i < 1000; i++) {
	var fileName = "test" + i;
	var directoryEntry = chromeFilesystem.root;
	var fileEntry = directoryEntry.getFile(fileName, {
		create : true
	});
	var writer = fileEntry.createWriter();
}


Is this similar to your download code where it crashes?

Yes, looks very similar to the code I provided in Comment 20, which is where I was seeing the crash in our app.

Sorry to ask for a status update but our customer is asking us.  The customer is Lee County Schools in NC, they have bought a lot of Chromebooks and a lot of them have this issue and crash as soon as they run our app so they are not able to use them like they want to.  Any info/update is greatly appreciated.

Thanks,
Keith

Hi all,

Is there any update on this and is there anything we can gather additionally to help?

Thanks!

We have a local repro and are debugging. I don't think we need additional data at the moment.

FYI on an update ... seems like there's a problem with garbage collection in the web file system implementation, which this patch will hopefully address: 
https://codereview.chromium.org/2009093002/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f466a07e32ce1c8083dc726c7391e68b2ff2e7b0

commit f466a07e32ce1c8083dc726c7391e68b2ff2e7b0
Author: achuith <achuith@chromium.org>
Date: Fri Jun 10 20:56:17 2016

Fix for sync filesystem app crash.

Previously removing the SafePointScope had a risk of producing a dead lock if the following scenario happens:

1) The main thread starts a GC and tries to stop all other threads.
2) The worker thread is waiting on a signal without entering the SafePointScope. The main thread cannot stop the worker thread forever and thus cannot make progress. Dead lock.

However, (to avoid this kind of dead lock) code has been added to timeout the GC if the GCing thread fails at stopping other threads within 100 ms. So not entering SafePointScope will just cause the timeout -- it won't cause a dead lock.

This fixes a hard-to-reproduce timing bug that's been a big concern of one of our partners.

BUG=592124, 608603 
TEST=manual

Review-Url: https://codereview.chromium.org/2009093002
Cr-Commit-Position: refs/heads/master@{#399265}

[modify] https://crrev.com/f466a07e32ce1c8083dc726c7391e68b2ff2e7b0/content/child/fileapi/webfilesystem_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d023da3f77306882389a2d8a09a7125815a00b31

commit d023da3f77306882389a2d8a09a7125815a00b31
Author: Achuith Bhandarkar <achuith@chromium.org>
Date: Tue Jun 14 19:41:36 2016

Fix for sync filesystem app crash.

Previously removing the SafePointScope had a risk of producing a dead lock if the following scenario happens:

1) The main thread starts a GC and tries to stop all other threads.
2) The worker thread is waiting on a signal without entering the SafePointScope. The main thread cannot stop the worker thread forever and thus cannot make progress. Dead lock.

However, (to avoid this kind of dead lock) code has been added to timeout the GC if the GCing thread fails at stopping other threads within 100 ms. So not entering SafePointScope will just cause the timeout -- it won't cause a dead lock.

This fixes a hard-to-reproduce timing bug that's been a big concern of one of our partners.

BUG=592124, 608603 
TEST=manual

Review-Url: https://codereview.chromium.org/2009093002
Cr-Commit-Position: refs/heads/master@{#399265}
(cherry picked from commit f466a07e32ce1c8083dc726c7391e68b2ff2e7b0)

Review URL: https://codereview.chromium.org/2065823003 .

Cr-Commit-Position: refs/branch-heads/2743@{#353}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/d023da3f77306882389a2d8a09a7125815a00b31/content/child/fileapi/webfilesystem_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f466a07e32ce1c8083dc726c7391e68b2ff2e7b0

commit f466a07e32ce1c8083dc726c7391e68b2ff2e7b0
Author: achuith <achuith@chromium.org>
Date: Fri Jun 10 20:56:17 2016

Fix for sync filesystem app crash.

Previously removing the SafePointScope had a risk of producing a dead lock if the following scenario happens:

1) The main thread starts a GC and tries to stop all other threads.
2) The worker thread is waiting on a signal without entering the SafePointScope. The main thread cannot stop the worker thread forever and thus cannot make progress. Dead lock.

However, (to avoid this kind of dead lock) code has been added to timeout the GC if the GCing thread fails at stopping other threads within 100 ms. So not entering SafePointScope will just cause the timeout -- it won't cause a dead lock.

This fixes a hard-to-reproduce timing bug that's been a big concern of one of our partners.

BUG=592124, 608603 
TEST=manual

Review-Url: https://codereview.chromium.org/2009093002
Cr-Commit-Position: refs/heads/master@{#399265}

[modify] https://crrev.com/f466a07e32ce1c8083dc726c7391e68b2ff2e7b0/content/child/fileapi/webfilesystem_impl.cc

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d023da3f77306882389a2d8a09a7125815a00b31

commit d023da3f77306882389a2d8a09a7125815a00b31
Author: Achuith Bhandarkar <achuith@chromium.org>
Date: Tue Jun 14 19:41:36 2016

Fix for sync filesystem app crash.

Previously removing the SafePointScope had a risk of producing a dead lock if the following scenario happens:

1) The main thread starts a GC and tries to stop all other threads.
2) The worker thread is waiting on a signal without entering the SafePointScope. The main thread cannot stop the worker thread forever and thus cannot make progress. Dead lock.

However, (to avoid this kind of dead lock) code has been added to timeout the GC if the GCing thread fails at stopping other threads within 100 ms. So not entering SafePointScope will just cause the timeout -- it won't cause a dead lock.

This fixes a hard-to-reproduce timing bug that's been a big concern of one of our partners.

BUG=592124, 608603 
TEST=manual

Review-Url: https://codereview.chromium.org/2009093002
Cr-Commit-Position: refs/heads/master@{#399265}
(cherry picked from commit f466a07e32ce1c8083dc726c7391e68b2ff2e7b0)

Review URL: https://codereview.chromium.org/2065823003 .

Cr-Commit-Position: refs/branch-heads/2743@{#353}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/d023da3f77306882389a2d8a09a7125815a00b31/content/child/fileapi/webfilesystem_impl.cc

Closing due to inactivity. Assume this is fixed now.