Bugzilla

(In reply to Jan de Mooij [:jandem] from comment #2)
> Can you give the m-c revision? Ion.cpp:457 is an empty line on m-c tip (well, Searchfox).


I was puzzled at that, too.
```
  454	  // Clean up if compilation did not succeed.
  455	  if (script->isIonCompilingOffThread()) {
  456	    script->jitScript()->clearIsIonCompilingOffThread(script);
* 457	
  458	    AbortReasonOr<Ok> status = builder->getOffThreadStatus();
  459	    if (status.isErr() && status.unwrapErr() == AbortReason::Disable) {
  460	      script->disableIon();
  461	    }
```

I have been updating M-C, C-C tree every two or three days for now.
And since the log quoted was taken on Oct 21, I can only say that the log was  taken with then current (maybe a couple of days old )
revision I fetched previously.
However, I have checked and found that the same warning at the same line 457 existed in the local log of Sept 25.

So, the problem has been persisting for a while and line the reported # has not changed.

And since the line # is both at 457, I think there is something fishy about this particular line #.
(I understand line # can be a bit fuzzy depending on the code motion due to even simple optimization. 
I suspect it could be either 456 or 458. Most likely 456?)

All I can say is that the problem is there between a relatively new head that is possibly only a couple of days old on Oct 21.

TIA

(In reply to Jan de Mooij [:jandem] from comment #2)
> Can you give the m-c revision? Ion.cpp:457 is an empty line on m-c tip (well, Searchfox).


I was puzzled at that, too.
```
  454	  // Clean up if compilation did not succeed.
  455	  if (script->isIonCompilingOffThread()) {
  456	    script->jitScript()->clearIsIonCompilingOffThread(script);
* 457	
  458	    AbortReasonOr<Ok> status = builder->getOffThreadStatus();
  459	    if (status.isErr() && status.unwrapErr() == AbortReason::Disable) {
  460	      script->disableIon();
  461	    }
```

I have been updating M-C, C-C tree every two or three days for now.
And since the log quoted was taken on Oct 21, I can only say that the log was  taken with then current (maybe a couple of days old )
revision I fetched previously.
However, I have checked and found that the same warning at the same line 457 existed in the local log of Sept 25.

So, the problem has been persisting for a while and the line # reported has not changed.

And since the line # is both at 457, I think there is something fishy about this particular line #.
(I understand line # can be a bit fuzzy depending on the code motion due to even simple optimization. 
I suspect it could be either 456 or 458. Most likely 456?)

All I can say is that the problem is there between a relatively new head that is possibly only a couple of days old on Oct 21.

TIA