Ok, I started following Ben's breadcrumbs. I'm on debian jessie also, 64bits. First, I could reproduce the issue (only if I maximize the image). And I started looking at the debugger/stack trace. The first thing I noticed is that with the debugger open in newFaceFromExternalMemory: aFreeTypeExternalMemory index: anInteger If I retry to evaluate self primNewFaceFromExternalMemory: aFreeTypeExternalMemory size: memSize index: anInteger. This always fails. I checked the Freetype plugin an the freetype library doc and my only guess is that the first argument (aFreeTypeExternalMemory) is wrong, or a remanent from another session. BUT! I made another discovery. If we actually walk to the top of the stack, we will see - the failure happens at startup, while starting up WorldMorph (what would explain why people observe this issue when saving the image) And, the redrawing happens because I maximized the window, what forces the morphs to redraw, explaining somehow why the bug appears when we maximize the window (?). - and then if we evaluate SessionManager default startupList we will see that WorldMorph is being started up before freetype. This means that the WorldMorph is being redrawn before freetype objects are cleaned, which may cause having wrong freetype handles/values. Of course, I'm half-way understanding all what's happenning :) These are all conjectures. But nevertheless, if somebody wants to try, I made a changeset (attached) that should be filed in and two lines that reset the session manager SessionManager default: SessionManager initializedSessionManager. SessionManager default installNewSession. Guille On Wed, Mar 16, 2016 at 7:09 PM, Ben Coman <btc@openinworld.com> wrote:
On Thu, Mar 17, 2016 at 1:07 AM, Ben Coman <btc@openinworld.com> wrote:
On Wed, Mar 16, 2016 at 8:36 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
On 16 Mar 2016, at 13:28, GitHub <noreply@github.com> wrote:
17797 random crash while trying to dispose a NULL handle https://pharo.fogbugz.com/f/cases/17797
again, this is an attempt against the "Font crashing VMâ bug⦠please I need all reports possible⦠even if you think is the same as before (even if IS the same as before).
"[A]" ImageWorker do: [ 1 + 1] within: 2 seconds onTimeout: [ self inform: 'timeout' ]
A1. Ran refresh.sh per last post and opened Image. A2. Opened playground without adjusting native window. A3. Three times successfully inspected [A], seeing "2". A4. Opened Nautilus and a few more times successfully inspected [A], seeing "2". A5. Maximised native window A6. Inspecting [A] caused forked child Image to remain open with error FT2Error: Freetype2 primitive failed [error 2][unknown file format]
Refinements... B1. Ran refresh.sh per last post and opened Image. B2. Opened playground without adjusting native window. B3. Three times successfully inspected [A], seeing "2". B4. Maximised native window B5. Inspecting [A] caused forked child Image to remain open with error
FT2Error: Freetype2 primitive failed [error 2][unknown file format]
C1. Ran refresh.sh per last post and opened Image. C2. Maximised native window. C3. Opened playground C4. Inspected [A] once, getting...
Error: External Image Failed: 34304
C5. Saved&quit Image C6. Restarted, got... stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 (Segmentation fault)
D1. Ran refresh.sh per last post and opened Image. D2. Opened playground D3. Inspected [A], successfully getting "2" D4. Several times, Saved Image, Restarted Image, goto D3. D5. Maximised window. D6. Inspected [A], forked child Image stayed open, playground is red-pane-of-death, predebug window... FT2Error: Freetype2 primitive failed [error 2][unknown file format] D7. Quit child Image without saving. D8. In parent, save&quit then restart produces error... stack page bytes 4096 available headroom 2788 minimum unused headroom 3020 (segmentation fault)
Btw, sometimes the the forked child Image (e.g. named 3635603974497675) that starts up, and sometimes the parent Image is started, so there are two native windows open titled "Pharo-5.0-Issue-Tracker-image.image" Both encounter similar frequency of FT2Error errors.
Trying incrementally changing resolution 244x665 okay = 2 244x683 okay = 2 244x695 okay = 2 244x709 child error FT2Error 244x685 okay = 2 (recovered) 244x700 okay = 2 244x705 parent error Error: External Image Failed: 34304 244x709 okay = 2 244x716 okay = 2 244x918 okay = 2 244x1147 child error FT2Error
The last one is full height. Now I repeatedly inspected [A] with strange results. Using CTRL-I would predominately fail with some successes. Most fails occurred in spawned Image with a FT2Error. Using "Inspect" from the context menu predominately succeeded, with some failures.
Also, sometimes the spawned image startup is s-l-o-w, so the 'timeout' inform executes, even though the inspect [A] successfully returns "2".
More mucking around indicates a definite tendency to error more often when the window is large.
cheers -ben