Cannot read property 'preProcess' of undefined

[Jason Grout]

Hi everyone,

On this page:

http://artsci.drake.edu/grout/calc3-fall2013/06-Derivatives.html

using the latest CDN MathJax, I consistently get an error on (the
latest) Chrome on OS X 10.6.8. Mathjax appears to start loading, but it
quickly says it is at 100%, but none of the math is typeset (and is
grayed out instead). In the console, I see:

Uncaught TypeError: Cannot read property 'preProcess' of undefined.

It says the error is on MathJax.js?config=TeX-AMS-MML_HTMLorMML:29

My students have also reported this problem on Chrome (I don't know what
operating system). At least one student said something like this
happened on IE. The page seems to consistently work in the latest
Firefox on OS X 10.6.8.

I've tried narrowing down the problem, and when I remove a large portion
of the page, sometimes it will work and sometimes it won't
(inconsistently, it will work for one refresh, but then not work when I
refresh again). I couldn't narrow it down to any specific tex on the page

I'm at a loss for how to narrow this down further or make this a better
bug report. Does anyone else using Chrome see these errors on the page
above?

Thanks,

Jason

--
Jason Grout

[Peter Krautzberger]

Hi Jason,

Can you try loading the unpacked version? I.e., http://cdn.mathjax.org/mathjax/latest/unpacked/MathJax.js?config=TeX-AMS-MML_HTMLorMML

Best,

Peter.

--
You received this message because you are subscribed to the Google Groups "MathJax Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mathjax-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Peter Krautzberger]

PS: I do see the same problem on Chrome 30 / linux. The unpacked version should give us more precise debugging information.

[Jason Grout]

On 10/21/13 2:05 PM, Peter Krautzberger wrote:
> PS: I do see the same problem on Chrome 30 / linux. The unpacked version
> should give us more precise debugging information.

Oh, right. Did you know any time you are viewing a "resource" in the
Chrome developers tools, you can auto-format it by going to the bottom
toolbar and clicking on the icon that looks like "{}"? That will
auto-format the code, and you can see the real line the error is on. I
use it all the time to debug minified javascript.

(see the "Reverse Engineering" point of
http://www.vodori.com/blog/developer-tools-google-chrome.html for a
screenshot, or the first answer at
http://stackoverflow.com/questions/4484407/human-readable-javascripts-in-chrome-developer-tools).

But anyway, I updated the page to use the unpacked version. And...it
works! So maybe the problem is in the minifier.

So now:

* http://artsci.drake.edu/grout/calc3-fall2013/06-Derivatives.html uses
the unpacked version and seems to work fine, and

*
http://artsci.drake.edu/grout/calc3-fall2013/06-Derivatives-minified.html uses
the minified version and has the error.

Thanks,

Jason

[Davide P. Cervone]

The timing of things using the combined configuration files is different between the minified and unpacked versions (the unpacked version just loads the required separate files, while the minified version actually includes all the files as one larger file). That does change the timing, since in the minified case, all the files are there initially, while in the unpacked version, they are loaded asynchronously and MathJax just wait for them. This does sometimes mean that one version will work when the other doesn't, especially when there is delicate timing interaction. That appears to be the issue here. I'm looking into it.

Davide

> --
> You received this message because you are subscribed to the Google Groups "MathJax Users" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to mathjax-user...@googlegroups.com.

[Peter Krautzberger]

Thanks, Jason. I am aware of the chrome dev tools. I had already noticed that the unpacked version did not experience the issue and wanted to confirm that. (The unpacked version would give better debugging information though.)

So, yes, it seems like a packing issue.  But it only happens on Chrome 30, not earlier versions. So it might be a browser bug that's involved.

Peter.

[Jason Grout]

On 10/21/13 3:50 PM, Peter Krautzberger wrote:
> Thanks, Jason. I am aware of the chrome dev tools. I had already noticed
> that the unpacked version did not experience the issue and wanted to
> confirm that. (The unpacked version would give better debugging
> information though.)
>

Sure; thanks.

> So, yes, it seems like a packing issue. But it only happens on Chrome
> 30, not earlier versions. So it might be a browser bug that's involved.

Yes, that's weird. And I had one student (on Windows, I believe) that
indicated that when he upgraded Chrome, it started working. But I don't
know what versions we are talking about; unfortunately I can't be more
specific.

Jason

[Jason Grout]

On 10/21/13 3:49 PM, Davide P. Cervone wrote:
> The timing of things using the combined configuration files is
> different between the minified and unpacked versions (the unpacked
> version just loads the required separate files, while the minified
> version actually includes all the files as one larger file). That
> does change the timing, since in the minified case, all the files are
> there initially, while in the unpacked version, they are loaded
> asynchronously and MathJax just wait for them. This does sometimes
> mean that one version will work when the other doesn't, especially
> when there is delicate timing interaction. That appears to be the
> issue here. I'm looking into it.

If you need the source with the extra css/javascript files, I can zip it
up and send it to you, if it would help. I do include a few small css
and javascript files to do the dynamic buttons, etc.

Thanks,

Jason

[Davide P. Cervone]

Thanks, but the file without them also exhibits the problem, so I'm able to work with that. I'll let you know what I find. It is peculiar.

Davide

[Peter Krautzberger]

FWIW for me, the page renders fine on Chrome 28, but breaks on Chrome 31beta.

[Davide P. Cervone]

There is something screwy in Chrome 30+.  It might be some kind of a memory bug.  One of MathJax's arrays is getting messed up for no reason, and the really strange part is that I have two console.log() messages, one right after the other, that both print the same value from an object in the array, and they produce different outputs!  There is no code between the two, and the property is just a string (so no special toString() functions running that might be causing a change).  The first log message prints the object whose property is being read (like the property was a circular reference to the object), and the second prints the correct value.  Really really weird.

It seems that any access to the data in the object "fixes" the problem.  So a line that simply references a property of the object (and does nothing with it) before the console.log() causes the output to be correct.  In my case the first console.log() causes the next one to be correct because Chrome made a reference to the object's data, and that fixed the object.

The incorrect reference doesn't always happen during the processing of the same TeX expression, but usually is around the same place (around the 397th expression).  That suggests that it might be that Chrome is doing some garbage collection or something, and gets it wrong somehow.  I'm really not sure what to say.  I can insert an unneeded reference to a property of the object to get around it in this case, but that sounds pretty fragile, and it might show up elsewhere.

I can also put a check in the location that is causing the error message and have it skip the expression that causes the funny memory issue, but it really should not be necessary, as what is happening shouldn't be happening.  It's only because accessing an objects property has returned the object rather than the property value that things are going awry.

I'm really at a loss to say what to do.

Davide

[Jason Grout]

On 10/21/13 6:15 PM, Davide P. Cervone wrote:
>
> I'm really at a loss to say what to do.

At what point do we report a bug to Chrome? What you mention sounds
pretty serious.

Jason

[Davide P. Cervone]

I think it will be difficult to produce a reduced test case for this, and I suspect they will not be too interested in looking at the very complex setup we currently have. But you never know, I guess.

I still want to do some more investigations to make sure I'm understanding thins properly.

Davide

[Davide P. Cervone]

I've done a little more work on trying to figure out what is going on, and I have a slightly better understanding (but only slightly better). The HTML-CSS output jax is stored as an object that has a number of properties, something like {id:"HTML-CSS", version:"2.2", fontDirectory: ...}. At some point during the processing of the mathematics, Chrome loses track of the mapping of the property names to their values. In particular, it seems to shift them all down by one position (so version now is associated with "HTML-CSS", and fontDirectory with "2.2", and so on). So it looks like an index that is used to address the properties gets off by one. But the first time one of the properties is accessed, the pointer gets fixed, and subsequent requests get the correct value (version is again attached to "2.2", etc.).

The mixup seems to occur when MathJax.Hub.saveScript() is called. If I put a console.log(MathJax.OutputJax["HTML-CSS"].version) just before the call to MathJax.Hub.saveScript() is made, the value is OK, but the same console.log() message as the first command inside the saveScript() function shows the shifted value (the value of the id property). None of the values that are passed to MathJax.Hub.saveScript() are related to MathJax.OutputJax, and the HTML-CSS output jax is not even created at the point that the saveScript function is defined, so the HTML-CSS object is not include in a closer for saveScript(). So I'm at a loss as to why there would be any effect on the HTML-CSS output Jax when calling the saveScript() routine, but it is pretty clear that there is one.

If you want to see it yourself, you can add

MathJax.Hub.SAVESCRIPT = MathJax.Hub.saveScript;
MathJax.Hub.saveScript = function () {
var HTMLCSS = MathJax.OutputJax["HTML-CSS"];
console.log([HTMLCSS.version,HTMLCSS.version,HTMLCSS.id]);
return this.SAVESCRIPT.apply(this,arguments);
}

at the bottom of your text/x-mathjax-config block in the page that is showing the problem. This traps the saveScript() function and prints the value of the version property (twice) and the id property from the HTML-CSS output jax every time saveScript() is called. (That will be a LOT of times.) The first two values should be the same, but you will see that about half way through, the first occurrence changes from "2.2" to "HTML-CSS" (the version becomes the id). But the second version is correct (the first reference has cured the problem).

Anyway, it is very strange. Perhaps it would be possible to submit the page with this extra configuration code as a bug report to Chrome, but I wouldn't hold my breath.

Davide


On Oct 22, 2013, at 7:11 AM, Jason Grout wrote:

[Jason Grout]

On 10/22/13 7:31 PM, Davide P. Cervone wrote:
> Anyway, it is very strange. Perhaps it would be possible to submit
> the page with this extra configuration code as a bug report to
> Chrome, but I wouldn't hold my breath.

That does seem very strange. I think it wouldn't hurt to submit a bug
report to Chrome---if they've seen other reports of things like this, it
might help them narrow down the problem.

In the meantime, do you happen to have a work-around that you could put
in the upcoming 2.3 release? This problem is making mathjax not work
very well for one of the more popular browsers out there unfortunately
(that's not the only page that has this problem, and at least one other
user reported the same problem [1]).

It's curious that the bug doesn't seem to happen with the unpacked
version. Or are you reproducing it even with the unpacked version of
MathJax?

Thanks,

Jason

[1] https://github.com/mathjax/MathJax/issues/605

[Davide P. Cervone]

> do you happen to have a work-around that you could put in the upcoming 2.3 release?

Well, I can work around the problem in this particular page, but I don't know whether it always manifests itself at this same function call. I have not reason to believe that similar issues might not occur elsewhere, and its really not possible to check every value of every object every time you use it to see if Chrome has screwed it up along the way somewhere. I'm hesitant to add extra (mysterious) code into this one routine for this when I don't know that it always occurs there.

> It's curious that the bug doesn't seem to happen with the unpacked version. Or are you reproducing it even with the unpacked version of MathJax?

No, it is only the packed version. As I mentioned earlier, I think this is due to a memory management problem in Chrome, and the memory usage is different for the packed version. Even loading a different config file (with the packed MathJax) can avoid the problem. So the circumstances that trigger the issue are pretty delicate.

Davide

[Jason Grout]

On 10/22/13 7:31 PM, Davide P. Cervone wrote:
> Anyway, it is very strange. Perhaps it would be possible to submit
> the page with this extra configuration code as a bug report to
> Chrome, but I wouldn't hold my breath.

Given that Chrome devs seemed to indicate today that they won't support
MathML right now because things like MathJax exist [1], perhaps they
would treat a bug report about MathJax with a high priority. Anyways,
it wouldn't hurt to submit it.

Thanks,

Jason


[1] https://code.google.com/p/chromium/issues/detail?id=152430#c43