1172873 - [B2G][STK] Suppress the notification of STK proactive command if there is no Icc detected.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Julien Wajsberg [:julienw]]

I get this issue when flashing the reference workloads on a master device:

06-09 12:00:03.830 15508 15508 E GeckoConsole: [JavaScript Error: "TypeError: icc.iccInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/IccService.js" line: 142}]
06-09 12:00:03.830 15508 15508 E GeckoConsole: [JavaScript Error: "NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "icc.iccInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/IccService.js" line: 142}]'[JavaScript Error: "icc.iccInfo is null" {file: "jar:file:///system/b2g/omni.ja!/components/IccService.js" line: 142}]' when calling method: [nsIGonkIccService::notifyStkCommand]" {file: "jar:file:///system/b2g/omni.ja!/components/RadioInterfaceLayer.js" line: 1068}]

This is critical for updates because the reference workloads uses an older format.

You can reproduce with this STR:

1. Run these commands:
  adb shell stop b2g
  adb shell rm -r /data/local/storage/permanent/chrome/idb/*ssm*
  APP=sms make reference-workload-light
  adb logcat

(note: the 2 first lines are unnecessary once bug 1172864 lands)

2. wait that the phone is starting.

3. launch the SMS app
=> observe the app stays blank

I checked that it does reproduce on master but doesn't reproduce on v2.1. I'm trying v2.2 now.

Comment 1

[Julien Wajsberg [:julienw]]

It looks fine in v2.2.

Bevis, if you look at the code where this breaks, is this also what you expect?

Comment 2

[Bevis Tseng[:bevis][:btseng](Exited)]

The error looks the same to bug 1170467.

Is this happened in open_c?

Is this problem recovered by the instruction in bug 1170467 comment 2?
$adb shell stop b2g; adb shell start b2g

In bug 1170467, this is an unexpected error if we got a STK proactive command from modem before we set STK ready to the modem.
We will set STK_SERVICE_READY to modem if we got iccInfo from modem.

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

set NI for the question in comment 2.

In addition, is this error printed due to the command in comment 0 or it always printed that cause the inserted SIM not detected at first bootup on "OPEN_C" only and can be recovered with the adb commands mentioned in comment 2?

Comment 4

[Julien Wajsberg [:julienw]]

I tried on Flame. This Flame has no SIM at the moment, so maybe that's the reason?

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #4)
> I tried on Flame. This Flame has no SIM at the moment, so maybe that's the
> reason?

Unlike bug 1170467, if this error doesn't cause anything malfunction, then we can add the protection back to supress this error which we thought it should never be happened and was removed when fixing bug 1114938.

Comment 6

[Julien Wajsberg [:julienw]]

When I restart using adb commands it seems we can recover -- but I think that sometimes I needed to do it twice.

Note that when the error happens the SMS app stays blank.

Also there is no difference if I have a SIM or not.

Comment 7

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Julien,

After further investigation,
I think the reason that the sms app stays in blank is because the db version you push into the device is too old which triggers the upgrade from version 11 to 23 and blocks the getThreads() request until the db upgrade is done.

A better way to resolve this is to have the newly upgraded db and files from the device as the test data for "make reference-workload-light" in m-c branch.

I'll update a patch to address the error message mentioned in comment 0.

Comment 8

[Bevis Tseng[:bevis][:btseng](Exited)]

Attachment: Patch: Suppress the notification of STK proactive command if there is no Icc detected.

Hi Edgar,

May I have your review for this quick fix?

Thanks!

Comment 9

[Julien Wajsberg [:julienw]]

> A better way to resolve this is to have the newly upgraded db and files from the device as the test data for "make reference-workload-light" in m-c branch.

Of course not ! Because the migration needs to work obviously :)
That's one of the goal of the reference workloads too (at least for me): make sure the migration works.

And currently it does not work at all (supposedly because of this bug, but maybe I'm wrong here).

Comment 10

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #9)
> > A better way to resolve this is to have the newly upgraded db and files from the device as the test data for "make reference-workload-light" in m-c branch.
> 
> Of course not ! Because the migration needs to work obviously :)
> That's one of the goal of the reference workloads too (at least for me):
> make sure the migration works.
Ok, now, I see the purpose of this reference workload. :)
> 
> And currently it does not work at all (supposedly because of this bug, but
> maybe I'm wrong here).

Unfortunately, I am not able to reproduce this error message with my flame device. :(
I can see the sms app stayed blank for 5~10 seconds and then the thread list was displayed.

Is it possible to give the patch in comment 8 a trial to see if the symptom can be resolved?

Thanks!

Comment 11

[Julien Wajsberg [:julienw]]

That's weird because I also not see the error message 100% of the time. I saw it 100% of the time when I filed the bug, but then later in the day I could not see it anymore. I don't know at all what changed...

Keeping the NI for now, I'll try later today.

Comment 12

[Bevis Tseng[:bevis][:btseng](Exited)]

update tryserver result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6e30ba424edd

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/b2g-inbound/rev/42b66e48e0c7

Comment 14

[Julien Wajsberg [:julienw]]

I'm sorry, I can't reproduce the original issue on current master; maybe this was happening because the old DB was not correctly removed before bug 1172864 landed ?

I still think it's good to prevent such things from happening... so we should land this :)

Comment 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/42b66e48e0c7

Comment 16

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Julien Wajsberg [:julienw] from comment #14)
> I'm sorry, I can't reproduce the original issue on current master; maybe
> this was happening because the old DB was not correctly removed before bug
> 1172864 landed ?
> 
Never mind!
> I still think it's good to prevent such things from happening... so we
> should land this :)
Sure! ;)