[Pharo-fuel] [Vm-dev] Fwd: Possible collections problem

[Max Leske]

Dave, you're a genius :)

When I started playing around with detaching / reattaching XDisplay and serializing without image fork I first found that I could reproduce the problem without a fork. The trick was to serialize in an additional fork after decapitating:

[ OSProcess thisOSProcess decapitate.
  NSSnapshotSerializer serialize: CTMSession rootModel.
  OSProcess thisOSProcess displayOnXServer: ':88' ] forkAt: 30

From there it seemed a good idea to see if other processes were interfering and of course the ui related processes came to mind:

[ OSProcess thisOSProcess decapitate.
  Project uiProcess terminate.
  InputEventFetcher shutDown.
  NSSnapshotSerializer serialize: CTMSession rootModel.
  
  InputEventFetcher startUp.
  Project spawnNewProcess.
  OSProcess thisOSProcess displayOnXServer: ':88' ] forkAt: 30

And halleluja! It worked!
Then I tried the same thing but in the forked image (with 10 repeats):

10 timesRepeat: [ [ 
	OSProcess thisOSProcess forkSqueakHeadlessAndDo: [ 
		Project uiProcess terminate.
  		InputEventFetcher shutDown.
  		NSSnapshotSerializer serialize: CTMSession rootModel ] ] forkAt: 30 ]


And voilà, every serialization terminated.

Thanks again for your help. You put me on the right track.


I verified that serialization works by simply terminating the event fetching process. This leads me to believe that the event fetching process can become locked (there's a semaphore for waiting on events). What I can't explain though is why the behavior was so erratic (serialization did work quite often). I can only guess that it might depend on the state of the semaphore when the image is being forked. Do you have an idea? BTW, I also found that I could bring the image back to life by forking a second process that suspended the serialization process after a couple of seconds and reattached the display. But this process ran at priority 40 (running fork of the serialization process with a different priority didn't help however).

One last question: should this go into OSProcess (I use a older version *cough cough* fo OSProcess and don't know what the changes)?

Cheers from very rainy Switzerland from a very happy Max :)



On 30.05.2013, at 15:38, vm-dev-request at lists.squeakfoundation.org wrote:

> A couple more debugging ideas:
> 
> Maybe you can get more clues by looking at a stack dump from the
> stuck process. You can ask the VM to dump stack on receipt of a unix
> signal like this (in this example I'm using SIGUSR1):
> 
>  OSProcess accessor setPrintAllStacksOnSigUsr1.
>  child := OSProcess thisOSProcess forkHeadlessSqueakAndDoThenQuit: [
>  	"do the serialization stuff" (Delay forSeconds: 10) wait
>  	].
> 
>  "wait for child to get stuck" (Delay forSeconds: 5) wait.
> 
>  "send SIGUSR1 to forked squeak, you can do this from unix console of course"
>  OSProcess accessor primSendSigusr1To: child pid.
>  OSProcess accessor clearPrintAllStacksOnSigUsr1.
>  child inspect.
> 
> Perhaps the issue is associated with the headless display (X11 disconnected)
> and does not have anything to do with the forked image per se. If so, it should
> be possible to reproduce the problem in a non-forked image by turning off the
> X display while serialization is being done:
> 
>  OSProcess thisOSProcess decapitate.
>  "Do serialization stuff" (Delay forSeconds: 5) wait.
>  OSProcess thisOSProcess recapitate.
> 
> Try that about 10 times and see if it ever gets stuck.
> 
> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130602/c130c423/attachment-0001.htm