Hi, As you can see in the crash dump, this is always due to FreeType. If it's only at start-up it means it's in the FreeType start-up code. You can try to change some free type settings (like not using those fonts at all) or to use more hard-core scripts such as: #(FT2Handle FreeTypeCache FreeTypeSettings) do: [ :each | SessionManager default unregisterClassNamed: each ] On Fri, Oct 20, 2017 at 5:50 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:

I've experienced the same thing on Windows 10 yesterday, but normally I do not work in P7 so I didn't investigate much.

On Fri, Oct 20, 2017 at 3:57 PM, Thomas Dupriez <thomas.dupriez@ens-paris- saclay.fr> wrote:

...

Hello,

I've had a few issues with Pharo 7 lately. After downloading pharo 7 images, doing some work in them and saving them, the images either instantly crashe or freeze when I try to re-run them. If that helps, I was working with and on the calypso browser.

Attached are the crash dump files from some of these faulty images.

vm version: 201708271955 image version: 6521 OS: Ubuntu 16.04 LTS

Cheers, Thomas

-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

On Sat, Oct 21, 2017 at 6:23 PM, Peter Uhnák <i.uhnak@gmail.com> wrote:

#(FT2Handle FreeTypeCache FreeTypeSettings) do: [ :each | SessionManager

...

default unregisterClassNamed: each ]

How am I supposed to launch the script if it crashes on startup? I've tried running from terminal but to no avail.

... I was talking about future images. If you want to save your already crashing image, the crash.dump says the VM crashes in FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: . So you need to interrupt that / change the behavior of one of the method leading to this behavior. What I would try: - start the image on a VM without Freetype (maybe you will have an error instead of a crash) - open a new image, and check what you could return immediately instead of executing one of the faulty method to start-up without a crash (For example, if I replace the method body of FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: by ^ self, does it crash ? If yes, pick another method upper in the crashing stack of crash.dump or return something else). Then, you can either: * start the image on the VMSimulator, set a break point on the method selector with the body you want to replace and change the runtime behavior to return the value you want instead. * open your crashing image with an hexadecimal editor, look for the bytecode sequence of the method with the body you want to replace, replace it with new bytecode to return the value you want. Save your image. Restart it on the VM. That kind of things. Best,

Thanks, Peter

-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Hi again, I checked with Stef this morning. Starting the image on a VM without Freetype solves the problem. Just open the VM, remove or rename the Freetype dynamic libraries (FT2, Freetype, 3 libs in total), then start your image. That's unfortunate the hexadecimal editor solution is so much more fun :-) Cheers On Sat, Oct 21, 2017 at 9:30 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

Thanks thomas we should find the problem.

Stef

On Fri, Oct 20, 2017 at 3:57 PM, Thomas Dupriez <thomas.dupriez@ens-paris-saclay.fr> wrote:

...

Hello,

I've had a few issues with Pharo 7 lately. After downloading pharo 7 images, doing some work in them and saving them, the images either instantly crashe or freeze when I try to re-run them. If that helps, I was working with and on the calypso browser.

Attached are the crash dump files from some of these faulty images.

vm version: 201708271955 image version: 6521 OS: Ubuntu 16.04 LTS

Cheers, Thomas

-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

On 24. Mar 2018, at 16:42, Holger Freyther <holger@freyther.de> wrote:

1.) FT2Handle class>>#startUp: isn't called. Which means FreeTypeFace>>#beNull has not been called yet!

I think implementing:

FreeTypeExternalMemory class >> #bytes: aByteArray ^(aByteArray copy) pin; yourself

could solve most of it? (We can argue about the copy...)

It doesn't because most of FT2Plugin expects the "handle" it invented. But if we look at it... FreeTypeFace>validate SmalltalkImage>session SessionManager class>default SessionManager>currentSession SmalltalkImage>session FreeTypeFace>create FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: FreeTypeExternalMemory>validate FreeTypeExternalMemory(FT2Handle)>isValid FreeTypeFace>>#validate already does: (session == Smalltalk session ... And this is why FreeTypeFace>>#create is being called and that will call validate on the FreeTypeExternalMemory instance... FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good. So back to the ideas. a.) Make sure FT2Handler class>>#startUp runs a lot earlier b.) Find out which UI thing uses freetype earlier (but FreeType can be used in non GUI apps. E.g. to draw text to an image...) c.) Keep the session in FreeTypeExternalMemory as well and use it in >>#validate.. (not relying on the startUp order) d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype.. holger

On 24. Mar 2018, at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Dear Eliot,

...

d.) Re-write FreeType with Alien and just use the Plugin to conveniently link/load to freetype..

I wonder if there is sense in trying to come up with a general memory handle object that includes a session identifier, so that attempts to free stake memory always fail.

I think it would help with the FT2Handle (to invalidate it on a new session) but it will not solve other image resume/FFI issues. Let's assume we have multiple calls into a C library (get a handle, call 1st method, call 2nd method, have a loop with backwards jumps). Something like: | memory | memory := GetSomeMemorySomewhere. 1 to: 5 do: [ self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. ... more C stuff ]. We could be interrupted at any point and when the execution is resumed the handles might be invalid. In Python terminology something like a context manager could help: # Image saving is delayed/inhibited until after the callout chain CCallOut with: [ 1 to: 5 do: [ self doSomeCStuffWithMemory: memory pointerAndCheckStillValid. ... more C stuff ]. ] What do you think? holger

On 26. Mar 2018, at 00:00, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Holger,

Hey!

Is the intent of CCallOut with: aBlock to collect and defer deallocations until the block completes? I think it's nice but complex and wonder how general it is. But it seems like it would impact a lot of code and require a lot of effort changing existing code bases. My handle scheme is only intended to fix the issue of images crashing on startup. The problems with crashing on startup being a) one loses one's work and b) the issue is hard to debug. That, for me, motivates something like the simple fix I p[roposed. I'm not standing in the way of something more beautiful, but I do believe that one shouldn't make the perfect the enemy of the good.

By all means, let's have a smart pointer! It will be beneficial for freetype and many other places. Nobody likes crashing images (for a mistake made in a previous run). My intent with the CCallOut is inhibit image saving until the code is outside a sequence of (interruptible, hence the backward jump int the example) C calls working with one or more pieces of manually managed memory. But maybe it is best to call it by what it does instead of finding a name of where it is used. I can't come up with a better example right now. But I think a Smartpointer wouldn't be of much help with a sequence of strtok calls. word := CStringAPI strtok: cStringPtr safeBytes separator: '\r'. [word isNil] whileFalse: [ word = 'Foo'... word = 'Bla'... word := CStringAPI strtok: nil separator: '\r' ------------- Image Save happening right here and word is not nil ----- ]. I hope this is more clear. holger

On 24. Mar 2018, at 17:03, Holger Freyther <holger@freyther.de> wrote:

FreeTypeExternalMemory>validate just checks if the handle isValid but remember 1st from my previous mail. We have not _yet_ cleared the FT2Handle SubInstances.. So the memory is all good.

The snippet below is my work-around. I think the proper fix is to get FT2Handle to invalidate handles a lot earlier (Gui->System startup?). Author useAuthor: 'Hacks' during: [ FreeTypeExternalMemory addInstVarNamed: 'session'. FreeTypeExternalMemory compile: 'validate (session == Smalltalk session and: [ self isValid ]) ifTrue: [ ^self ]. bytes ifNil: [ ^ self ]. session := Smalltalk session. self primCopyToExternalMemory: bytes. self isValid ifTrue: [ self class register: self ]' ]. Smalltalk snapshot: true andQuit: true.