another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

Dale Henrichs-3
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 (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

EstebanLM
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 <[hidden email]> 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>


Reply | Threaded
Open this post in threaded view
|

Re: another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

Mariano Martinez Peck
For the record, I do also continue to see this crash in Pharo 5.0 with it's stable VM. 
But as Esteban said, it's too random that I don't have more info to share :(


On Mon, Aug 8, 2016 at 6:39 AM, Esteban Lorenzano <[hidden email]> wrote:
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 <[hidden email]> 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>





--
Reply | Threaded
Open this post in threaded view
|

Re: another segfault from Pharo5.0 vm (freshly downloaded today) Ubuntu 14.04

stepharo

Me too I get from time to time a VM crash (sometimes after a smalltalkhub hiccups).

Stef


Le 8/8/16 à 15:26, Mariano Martinez Peck a écrit :
For the record, I do also continue to see this crash in Pharo 5.0 with it's stable VM. 
But as Esteban said, it's too random that I don't have more info to share :(


On Mon, Aug 8, 2016 at 6:39 AM, Esteban Lorenzano <[hidden email]> wrote:
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 <[hidden email]> 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>





--