damn :( FreeType bug strikes again… :(( to be honest, I’m playing with the idea to completely replace it with a UFFI version. I cannot find why/how this happens… in some conditions handle become invalid and pharo has no idea pointer is not valid any more… then crash. Double free was what I guess but I do not find where that happens (the double free). And I’m also open to believe in some memory handling problem in VM, now :((
Esteban > On 05 Aug 2016, at 22:55, Dale Henrichs <dale.henri...@gemtalksystems.com> > wrote: > > Attached crash dump file ... > > This one occurred after I'd had an image open for several hours interesting > that similar to the other crashes I've seen recently FreeTypeFace seems to be > implicated: > > Smalltalk stack dump: > 0xff7bc02c I [] in FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10: a(n) > FreeTypeFace > 0xff7bc04c M BlockClosure>ensure: 0x9edc9b0: a(n) BlockClosure > 0xff7bc078 I [] in Mutex>critical: 0xadc7960: a(n) Mutex > 0xff7bc098 M [] in Semaphore>critical: 0xba42d50: a(n) Semaphore > 0xff7bc0b8 M BlockClosure>ensure: 0x9edcab8: a(n) BlockClosure > 0xff7bc0d8 M Semaphore>critical: 0xba42d50: a(n) Semaphore > 0xff7bc100 I Mutex>critical: 0xadc7960: a(n) Mutex > 0xff7bc124 I FreeTypeFace(FT2Handle)>pvtDestroyHandle 0xcdeae10: a(n) > FreeTypeFace > 0xff7bc13c M FreeTypeFace(FT2Handle)>finalize 0xcdeae10: a(n) FreeTypeFace > 0xff7bc154 M ByteSymbol(Symbol)>value: 0xa3ab850: a(n) ByteSymbol > 0xff7bc178 M ObjectFinalizerCollection(OrderedCollection)>do: 0xaa62580: a(n) > ObjectFinalizerCollection > 0xff7bc19c I ObjectFinalizerCollection>finalize 0xaa62580: a(n) > ObjectFinalizerCollection > 0xff7bc1c0 I WeakFinalizerItem>finalizeValues 0xb8cae80: a(n) > WeakFinalizerItem > 0xff7bc1dc M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry > 0xff7bc1f4 M BlockClosure>on:do: 0x9edc8a8: a(n) BlockClosure > 0xff7bc214 M BlockClosure>on:fork: 0x9edc8a8: a(n) BlockClosure > 0xff7bc234 M [] in WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry > 0xff7bc258 M OrderedCollection>do: 0x9edc450: a(n) OrderedCollection > 0xff7bc280 M WeakRegistry>finalizeValues 0xa6dd690: a(n) WeakRegistry > 0xff7bc29c M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) > WeakArray class > 0xff7bc2b4 M BlockClosure>on:do: 0x9edc398: a(n) BlockClosure > 0xff7bc2d4 M BlockClosure>on:fork: 0x9edc398: a(n) BlockClosure > 0xff7bc2f4 M [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) > WeakArray class > 0xff7bc318 M WeakArray(SequenceableCollection)>do: 0xa381328: a(n) WeakArray > 0xff7bc33c I [] in WeakArray class>finalizationProcess 0xa5cefc0: a(n) > WeakArray class > 0xff7bc35c M [] in Semaphore>critical: 0xcc147b0: a(n) Semaphore > 0xff7bc37c M BlockClosure>ensure: 0x9edb760: a(n) BlockClosure > 0xff7bc39c M Semaphore>critical: 0xcc147b0: a(n) Semaphore > 0xff7bc3c0 I WeakArray class>finalizationProcess 0xa5cefc0: a(n) WeakArray > class > 0xbd19fe8 s [] in WeakArray class>restartFinalizationProcess > 0xce10050 s [] in BlockClosure>newProcess > > Looks like pvtDestroyHandle went a little overboard:) > > Dale > <crash.dmp>
