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