839849 - DeviceStorage: crash with message: [AsyncChannel] Error: Channel error: cannot send/recv

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect)

Description

[David Flanagan [:djf]]

Attachment: logcat output from the crash

I've been trying to modify the Gaia Gallery app to not use IndexedDB and instead store its data directly on the sdcard.

Sometimes the app crashes when I write a blob to a file. The blob I'm trying to write is created with the new Blob() constructor from an array that consists of typed arrays, other blobs, and a long string.

I'm using device storage type 'sdcard' when this crash happens.

I've attached the logcat for the full set of error messages from this crash.

I suspect this has more to do with the complex Blob that I'm trying to write than it does with device storage, but I'm cc'ing Doug.

Comment 1

[David Flanagan [:djf]]

I'm nominating tef? because this is a crash

Comment 2

[David Flanagan [:djf]]

Another possibly relevant point...

Before writing the file, I delete it:

      // First, delete the old file.
      scanner.sdcard.delete(scanner.indexfilename);

      // Then save the new one
      var savereq = scanner.sdcard.addNamed(blob, scanner.indexfilename);
      
This is because addNamed() will fail if the file already exists.  Note, however, that I don't wait for the delete() call to succeed or fail. I just assume that the two calls on the same device storage object will be serialized.  Maybe there's a race condition here that causes the crash?

Comment 3

[David Flanagan [:djf]]

I've changed my device storage code so it waits for the delete to succeed or fail before doing the save, but that doesn't help.

I can reproduce this crash consistently by taking a picture with the camera while the gallery is running. The gallery sees the new photo and tries to save its new state to the sdcard. Unfortunately, this is with a new experimental version of the gallery app that I haven't checked in anywhere, so I can't give steps to reproduce that will work for anyone else.

I'm seeing this in a b2g18 build from 20130205104438

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Is there anything we're shipping currently in the phone that replicates the type of Blob writes you're trying to do here?  Currently this does not look to be a blocker since it involves a lot of custom experimentation that would be unlikely to widely reproduce in the wild.  However, please renominate if we're missing something here that would affect the current shipping code with reliable reproducibility.

Comment 5

[Doug Turner (:dougt)]

david, do you have a test case or str?

Also, how big/long are the typed arrays, other blobs, and a long string that you are using to create the blob?

ben, do you have a logging patch that might help tell us what is failing?

Comment 6

[Sotaro Ikeda [:sotaro]]

(In reply to David Flanagan [:djf] from comment #0)
> Created attachment 712238 [details]
> logcat output from the crash
> 

It seems that the logcat started after child process crash.

Comment 7

[Ben Turner (not reading bugmail, use the needinfo flag!)]

It's very unclear what is going on here. We're likely going to need debug builds and crash stacks before this starts to make any sense I think.

Comment 8

[David Flanagan [:djf]]

(In reply to Doug Turner (:dougt) from comment #5)
> david, do you have a test case or str?

No, I don't. The code was on a branch I'm not working on right now, and I don't have time to go back to it.  I've got a tef+ blocker...  I think I even found some kind of workaround.

> 
> Also, how big/long are the typed arrays, other blobs, and a long string that
> you are using to create the blob?

The format of my blob was:

  [4-byte array buffer ~8kb blob]* 4 bytes of 0s ~100kb string

There were between 0 and 15 of the initial buffer,blob pairs. The buffers were just there to hold the length of the blob that followed.
 
> ben, do you have a logging patch that might help tell us what is failing?

Sorry to not be more helpful.

Comment 9

[David Flanagan [:djf]]

(In reply to Sotaro Ikeda [:sotaro] from comment #6)
> (In reply to David Flanagan [:djf] from comment #0)
> > Created attachment 712238 [details]
> > logcat output from the crash
> > 
> 
> It seems that the logcat started after child process crash.

The logcat started before that; I just cut what I thought were the interesting parts.  I don't recall seeing any messages about the child process crash, but maybe I just overlooked that.

Comment 10

[Martijn Wargers (dead)]

Still an issue?

Comment 11

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. 

If I incorrectly invalidated something, please let me know.

Comment 12

[Firefox Bug Husbandry Bot]

Bulk correction of resolution of B2G bugs to INCOMPLETE.