On Tue, Sep 13, 2016 at 01:44:05AM +0100, Guillaume Munch wrote: > Le 12/09/2016 à 19:35, Enrico Forestieri a écrit : > > On Mon, Sep 12, 2016 at 05:01:33AM +0200, Enrico Forestieri wrote: > > > > > > You can spare your time as I think I found the problem. The patch simply > > > uncovered a latent bug. The crash only occurs when there is a user > > > defined math macro. In this case, d->macro_->symbol() may return bogus > > > values. For a user defined macro it should always return a null pointer, > > > but for unknown reasons it sometimes returns strange values, which are > > > clearly bogus and cause a crash when dereferenced. > > > > > > I did not succeed in understanding why this occurs. > > > > I have found that this occurs because of some missing metric updates. > > The attached alternative patch covers all cases except one. This is the > > case in which user defined math macros are present _and_ instant preview > > is active. I did not find a solution for this case, so the previous patch > > is better. However, there are other cases in the sources in which the > > sym_ member of MacroData (the one returned by d->macro_->symbol()) is > > used. In these cases it is accessed only after checking that it is not > > null, but, as this case shows, this does not gaurantee that it is usable > > and a crash would occur. However, these cases are mainly related to the > > xhtml output, so they are not as frequent, possibly. > > > > > Hi Enrico, thanks for looking into it. These macros truly look like a > mine field. Unfortunately it still segfaults (though with a different > backtrace). I did not have the time to build a test case today.
The symptom seems to be the same, so I am maybe missing some case. Unfortunately, without a test case there is not much I can do. In the mean time I will commit both patches, as the alternative one will also help in the other cases mentioned above and then we can start from there. However, from next week I will not have time anymore. -- Enrico
