Tweak update...

gettimothy via Squeak-dev <[email protected]>
Newsgroups gmane.comp.lang.smalltalk.squeak.general
Message-ID <[email protected]>
very interesting and intense (for me) debugging going on...





I learned this morning that I can connect gdb to the running image and get some info from it...



which gdb || echo "need to install gdb"

gdb -batch -p "$VM" -ex 'call (void)printAllStacks()' -ex detach -ex quit

cat /tmp/vm-claudetweak.log



from that, we could infer that the supposed Morphic hang was not an issue at all, 


<begin_ai_generated>







Decoded socket reopen failure, pinpointed snapshotPrimitive as culprit




We found it — and it's not where the source archaeology kept looking.

The active process is ProcessorScheduler class>idleProcess at priority 10. That single line is the hang: the VM is idling because every other Smalltalk process is parked in a normal wait, so there's nothing runnable and it sits in epoll_wait (your gdb backtrace) ticking the trickle of CPU we measured. No crash, no C-level deadlock, no poisoned startUp method. Startup simply never finished.

The process that matters is 0xde03408, priority 30:









MCPServer class>startTCPServer → MCPTCPTransport>start → Socket>waitForAcceptFor: → … → Semaphore>wait



The MCP server is blocked in waitForAcceptFor: — waiting to accept a client — yet ss says 9877 isn't listening. Those two facts reconcile only one way: this is a stale socket from before the snapshot. The Socket object survived into the saved image still "in accept," but the OS socket behind it died when the previous VM exited. It's waiting on a semaphore that a dead fd will never signal, and nothing rebinds 9877. And it's not alone — process 0xde18db0 is a second listener, WebServer>runListener, frozen in the exact same waitForAcceptFor: on its own dead socket. Both servers froze mid-accept.

So the reframe: this is the socket-reopen-on-resume path — your Option 2 black box — and we're watching it die. The chain:

Loading Morphic broke the shutdown list.

Broken shutdown list → you had to save with bare snapshotPrimitive.

snapshotPrimitive skips the shutdown/startup processing that snapshot:andQuit: wraps around it — so the live MCP and Web server processes got frozen into the image mid-accept instead of being stopped first, and on resume nothing re-ran the step that reopens 9877.


Morphic's actual crime was breaking the shutdown list; the boot hang is a downstream consequence of the save method, not Morphic startup code. That's exactly why reading Morphic's startUp/shutDown hooks never found it — the bug is the absence of a clean save-and-reopen, not a poisonous method. (The Morphic world process 0xdb42258, PasteUpMorph>doOneCycle in interCyclePause:, is the new-in-20 piece and almost certainly the source of the slowly-climbing CPU — it's cycling its idle loop. A passenger, not the blocker.)









the OpenSmalltalk VM keeps its debug print functions (printAllStacks, printCallStack, printOop, …) exported even in release builds  

</end_ai_generated>





that was fixed and a milestone reached....



Onward!

Squeak-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.