930605 - [1.3] Email app does not launch

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Mandyam Vikram]

On launching the Email app, a white screen is displayed and the app is not functional.

Versions:
Gecko:
f25b780813123fbdaae0abb2873c50f79b60b509
Gaia
3d4f1107e6e91e5f5649edc0f2565ac837111d7d

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Do you have a build log or a reference to the build log in question or an adb logcat?  Usually when this happens, the problem is the build process failed and the email app zip is completely empty.  This will correlate with the icon for the app becoming the default rocket ship icon since there is no icon in the zip file.

Comment 2

[Benjamin Danon]

I have the same problem on FxOS 1.3.

My Geeksphone Keon was :
- on 1.1.0.0-prerelease, (Gecko: 1678124, Gaia: edd44ef)
I upgraded it
- to 1.2.0.0-prerelease (Gecko: ab2e967, Gaia: b67568c)
- and then to 1.3.0.0-prerelease (Gecko: 0121083, Gaia: 5311b40)

Furthermore, I have no problem with the icon, this is not the default rocket ship icon.

I attach the logcat related to the opening of the app.

Comment 3

[Benjamin Danon]

Attachment: logcat related to the opening of the email app

Comment 4

[Noemí Freire (:noemi)]

Hi,

It also occurs on v1.2 branch with today's (10/29) build on Unagi device:
Build Id: 20131029070352
gecko: 76298d3
gaia: 2ad6152
platform version: 26.0a2

because of this, asking for koi?

Comment 5

[Jason Smith [:jsmith]]

(In reply to Noemí Freire (:noemi) from comment #4)
> Hi,
> 
> It also occurs on v1.2 branch with today's (10/29) build on Unagi device:
> Build Id: 20131029070352
> gecko: 76298d3
> gaia: 2ad6152
> platform version: 26.0a2
> 
> because of this, asking for koi?

I'm not sure if the bug originally as filed here was the same issue you are seeing. The email app was launching fine on 10/24 during our daily smoketests, which makes me think this could be a different issue if this shows up in today's smoketest.

Comment 6

[Noemí Freire (:noemi)]

Attachment: Email app behavior on v1.2 branch

Hi,

I'm experiencing on today's build on v1.2 branch the same behavior explained in the description: when launching email app a white screen is shown and the app is not functional. Attaching a video to illustrate it.

Comment 7

[James Burke [:jrburke]]

Doing a first pass at the logcat, the relevant lines seem to be:

I/Gecko   ( 3293): WLOG: Email knows that it is: online and previously was: online
I/GeckoDump( 3293): ERR: indexedDB error: UnknownError from request as part of NO transaction on unknown source
I/GeckoDump( 3293): ERR: onerror reporting: UnknownError @ app://email.gaiamobile.org/js/ext/mailapi/main-frame-setup.js : 4019

Looking at line 4019 in Gaia 5311b40, I believe is this line:

https://github.com/mozilla-b2g/gaia/blob/5311b40f07e18fb612ce80804ff16ab5010da54a/apps/email/js/ext/mailapi/main-frame-setup.js#L4019

So, likely the IndexedDB open call:

    var openRequest = IndexedDB.open('b2g-email', dbVersion)

Not sure yet why the call fails.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Benjamin Danon from comment #3)
> Created attachment 823980 [details]
> logcat related to the opening of the email app

Thanks for the log!  Besides knowing the device type and build/hash id's, this is the most useful thing that can be provided!

Best guess is that your indexedDB database is corrupt.  On my v1.1 GP Keon, the e-mail DB lives at:
/data/local/indexedDB/1008+f+app+++email.gaiamobile.org

If you enable remote debugging via https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Debugging/Developer_settings and have adb available on your computer, you should be able to turn on "remote debugging" and then use "adb shell" and "ls" to see what's in the dir, then "adb pull" to back-up the database.  Then, you can use "adb shell" and "rm" and "rmdir" to nuke the existing database.  Of course, do this with the e-mail app already closed by long-pressing the home button and hitting the 'x' or swiping up to kill the e-mail app.

Then you should be able to start the e-mail app and based on whether or not it works, we can conclude whether it was a corruption issue or not.

If it was a corruption issue, we may want to get a look at your IndexedDB database, although depending on how well the e-mail app worked for you previously and how corrupt it is, there may be some private data in there that can be hard to redact because it will be hidden by compression and any attempts to redact might corrupt the DB more.

Comment 9

[Benjamin Danon]

I understood my problem… There was no sqlite database in the 1008+f+app+++email.gaiamobile.org directory, but only the sqlite-journal file, and I don’t know why. For information, the exact directory on 1.3 is now /data/local/storage/persistent/1008+f+app+++email.gaiamobile.org/idb/.
I solved my problem just by pushing a recent backup of my sqlite email database, which is not corrupted.
Mandyam should have another problem, sorry for the disruption.
Thank you for helping me.

Comment 10

[Mandyam Vikram]

When I flashed the same build again on the same device, the problem seems to have gone away. I can only suspect that it must have been some database issue like was mentioned earlier.

Comment 11

[Jason Smith [:jsmith]]

This sounds like a data migration bug between releases. Our daily smoketests show the email app working fine, which makes me think this is only happening if you've migrated from 1.1 to 1.2.

Comment 12

[Andrew Overholt [:overholt]]

Do we support (and test) data migration with upgrades?  If Jason's correct that this was caused by data migration, this sort of issue would block and should be renominated.

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Automated test-wise, test_activesync_recreate.js in GELAM tests core database migration logic at an application level.

QA manually tested migration to 1.1 and there was a bug found in bug 887700 which was a result of us *not* bumping the DB revision and some inconsistencies between the 1.0.1 codebase and the 1.1 codebase.

At first glance, Benjamin's problem sounds like it might be a lower level IndexedDB or SQLite problem, potentially related to the presence of the SQLite journal without the actual SQLite database.  Since we know the databases got moved around on the file-system and I have no idea how that happens, something weird could happen there.

However, I just did a quick SQLite source dive and the hasHotJournal spec requires that "The database file itself is greater than 0 bytes in size" for a journal to be interpreted as hot and therefore to pose a weird problem.  (It actually does a page count, which is indeed a better idea.)

And since IndexedDB also explicitly handles NS_ERROR_FILE_CORRUPTED by nuking and re-opening, database corruption shouldn't sink us.  Permission problems could, but I would not expect things to have resolved themselves with an "adb push" in this case unless it cleans up directory permissions as it traverses the file-system.

So basically I have no idea what could have happened.  If the problem happened post-file-open, the mozStorage PR_Log stuff might have something, but sqlite3_trace only happens after open.


For anyone else who wants to try some theories, these are the database versions we use, so the upgrade logic would only have fired on the v1.1 -> v1.2 transition, not the v1.2 -> v1.3 transition.  (And the same logic would apply for v1.1 -> v1.3)

gaia/v1.0.1: version 21
gaia/v1.1: version 21
gaia/v1.2: version 22
gaia/master: version 22


So in general I don't think there's any immediate migration problem we can look into unless someone is able to repro this and we can slap gdb on or something like that.

Comment 14

[Mandyam Vikram]

This is not an issue on a subsequent build. So, this is not a blocker from our side for 1.2.

Comment 15

[Dietrich Ayala (:dietrich)]

Looks like this is not actionable. Andrew, can you close it if that's the case?

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

I think this bug breaks down into Benjamin's exotic IndexedDB problem and probably other instances of bug 931550 (building with make -jN  breaks e-mail/clock) which is now fixed.

I've spun off bug 939183 about improving our IndexedDB to have better error logging or recovery for cases like this.  We will probably wait for more appearances of this exotic problem before delving into that more deeply since it is identifiable via logcat output and this is the first and only case we've seen of it.

Resolving WFM.