Apache OpenOffice (AOO) Bugzilla – Issue 127929
Possible crash in Freetype code
Last modified: 2022-10-28 12:54:25 UTC
Created attachment 86540 [details] Check the return value of the FT_Get_Glyph() function Method FreetypeServerFont::InitGlyphData() calls function FT_Get_Glyph() but does not check its return value. On my system, the function fails when selecting the ``slide master'' in Impress, and the program crashes because the method continues with invalid data. The attached patch repeats the same check as the previous call to FT_Load_Glyph(). Please note I have no idea what a glyph is, what those FT_ functions do, and why they fail. But the attached patch solves the crashes on my systems (tested on Linux) and looks logical IMHO. I suppose the same problem is present in version 4.1.5 (Linux and FreeBSD), because it also crashes when selecting the slide master view. Please let me know if you need any more information.
*** Issue 127805 has been marked as a duplicate of this issue. ***
Thanks a lot for the patch, we Try and come back for feedback :)
Thank you Arrigo Marchiori for fixing this crasher!
(In reply to Pedro from comment #3) > Thank you Arrigo Marchiori for fixing this crasher! You are welcome! Please excuse me if the question is silly, but why did you mark it resolved-fixed if trunk is still affected?
Hi Pedro, Please do not set an issue to RESOLVED/FIXED before the patch is in the code. But we can leave it for now, as I plan to commit it to trunk soon...
"mseidel" committed SVN revision 1846349 into trunk: i127929 - Fix for crash in Freetype code
(In reply to Arrigo Marchiori from comment #4) > Please excuse me if the question is silly, but why did you mark it > resolved-fixed if trunk is still affected? I do not know if trunk is still affected. I could not compile and test a binary from trunk. What I do know is that it is fixed in the 4.1.6 branch which is the one we are currently testing. Hopefully it will be fixed on trunk as well :) Since Matthias has committed your patch to trunk, I can test it soon. (In reply to Matthias Seidel from comment #5) > Hi Pedro, > > Please do not set an issue to RESOLVED/FIXED before the patch is in the code. > > But we can leave it for now, as I plan to commit it to trunk soon... Sorry! Thanks!
(In reply to Pedro from comment #7) > (In reply to Arrigo Marchiori from comment #4) > > > Please excuse me if the question is silly, but why did you mark it > > resolved-fixed if trunk is still affected? > > I do not know if trunk is still affected. I could not compile and test a > binary from trunk. What I do know is that it is fixed in the 4.1.6 branch > which is the one we are currently testing. Hopefully it will be fixed on > trunk as well :) Hi Pedro, Sorry, this is *not* fixed in 4.1.6. Unfortunately this patch was too late for the release in process... > Since Matthias has committed your patch to trunk, I can test it soon. But I can confirm that this is fixed in trunk with latest build from buildbot on Ubuntu 18.04.1 x64. Regards, Matthias
> Sorry, this is *not* fixed in 4.1.6. > Unfortunately this patch was too late for the release in process... I meant that the patch worked in 4.1.6 and the problem was fixed. It is unfortunate that it wasn't included in 4.1.6 > But I can confirm that this is fixed in trunk with latest build from > buildbot on Ubuntu 18.04.1 x64. Excellent!
set new importance
backdate to 4.1.6 and target milestone is 4.2.0 / 4.1.7 (when it gets done)
*** Issue 128193 has been marked as a duplicate of this issue. ***