I meant to also post a link showing the pattern of the recent primitives...

https://docs.google.com/spreadsheets/d/1QzY8iL_3kvHJg1xMg1yvCFzDpQf3Tl9zuVkzfom4cx4/edit?usp=sharing

On Tue, 13 Nov 2018 at 00:50, Ben Coman <btc@openinworld.com> wrote:

On Mon, 12 Nov 2018 at 21:37, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,

I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles.

Just to confirm, you mean your laptop sleep/wake cycle.
On my Window 10 laptop I do the same quite often with no problems.
��
For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly).

Here is a crash dump from today (fresh image/vm from WE, nothing special loaded).

Related to scheduling ? Event handling ?

In trying to understand the last few moments, is the recent primitives list strongly ordered in time?...
�� Most recent primitives
�� signal
�� nowTick
�� primSignal:atUTCMicroseconds:
�� wait
�� millisecondClockValue
�� @
�� actualScreenSize

Starting at #actualScreenSize, instrumenting the code by adding...
�� Transcript crShow: thisContext sender printString.
indicates the following call chain...
�� DisplayScreen-class>>actualScreenSize
�� MorphicUIManager>>checkForNewDisplaySize
�� DisplayScreen class>>checkForNewScreenSize
�� WorldState>>doOneCycleNowFor:
��WorldState>>doOneCycleFor:
�� WorldMorph>>doOneCycle
��WorldMorph class>>doOneCycle
�� MorphicUIManager>>spawnNewProcess

In detail from a static analysis of the code...
�� > WorldState>>doOneCycleNowFor:��
�� > DisplayScreen class>>checkForNewScreenSize
�� > MorphicUIManager>>checkForNewDisplaySize��
�� > DisplayScreen-class>>actualScreenSize�� PRIMITIVE��
�� < MorphicUIManager>>checkForNewDisplaySize��
�� < DisplayScreen class>>checkForNewScreenSize��
�� < WorldState>>doOneCycleNowFor
�� < WorldState>>doOneCycleFor:��
�� < WorldMorph>>doOneCycle��
�� < WorldMorph class>>doOneCycle��
< MorphicUIManager>>spawnNewProcess��
�� > WorldMorph class>>doOneCycle��
�� > WorldMorph>>doOneCycle
�� > WorldState>>doOneCycleNowFor:��
�� > WorldState>>interCyclePause:
�� > Time>>millisecondClockValue�� PRIMITIVE
�� < WorldState>>interCyclePause:
�� > Delay>>schedule
�� > DelaySemaphoreScheduler>>schedule:
�� > Semaphore>>wait�� PRIMITIVE "readyToSchedule variable"
�� > Semaphore>>signal�� PRIMITIVE "timingSemaphore variable"�� NOT RECORDED
�� maybe context change causes this to be recorded later in "Most recent primitives"
�� > DelayMicrosecondTicker>>waitForUserSignalled:orExpired:�� waking up from Semaphore>>wait��
�� the primSignal:atUTCMicroseconds:�� PRIMITIVE�� immediately before the #wait seems to have been logged now��in "Most recent primitives"
�� > DelaySemaphoreScheduler>>scheduleAtTimingPriority
�� > Semaphore>>signal�� PRIMITIVE�� "readyToSchedule variable"�� seems to have not been recorded in "Most recent primitives"
�� > DelayBasicScheduler>>scheduleAtTimingPriority
�� < DelaySemaphoreScheduler>>scheduleAtTimingPriority
�� < DelayBasicScheduler>>runBackendLoopAtTimingPriority
�� > DelayMicrosecondTicker>>nowTick�� PRIMITIVE��
�� > Delay>>timingPrioritySignalExpired��
�� > Semaphore>>signal�� PRIMITIVE "delaySemaphore variable"�� CRASH

��Smalltalk stack dump:
�� 0x7ffee21d7138 M Delay>timingPrioritySignalExpired 0x113e3b138: a(n) Delay
�� 0x7ffee21d7170 M [] in DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority 0x11453b8c0: a(n) DelaySemaphoreScheduler
�� 0x1169f51c8 s BlockClosure>ensure:
�� 0x1169f5828 s DelaySemaphoreScheduler(DelayBasicScheduler)>runBackendLoopAtTimingPriority
�� 0x1169f5c38 s [] in DelaySemaphoreScheduler(DelayBasicScheduler)>startTimerEventLoopPriority:
�� 0x1169fae10 s [] in BlockClosure>newProcess

The only reason I can think that last semaphore call would be a problem is if variable delaySemaphore was not a Semaphore,
but the C stack backtrace doesn't look like it crashes in the Semaphore handling.
Its perhaps co-incidental with delay scheduling code is invoked fairly often, that its the current process when this crash occurs.

To hep isolate the failure point, I would considering copying #nowTIck to a multiple series like...
#nowTick1
#nowTick2
#nowTick3
etc so that all of the sender sites can be made distinct.
And maybe the same for #signal senders within the delay scheduling code.

One side-curiousity is I can't see where the primitive #@ is being called from.
Does it indicate some loop as its trying to determine��

To me the "vmIOProcessEvents" in the C backtrace with a fairly deep stack into the AppKit framework��
indicates its related to event handling.

cheers -ben