Hi Göran, thanks for the image. It really does make the difference between total speculation and finding a plausible explanation.
As it turns out, the root Q2User's model's processes is a proxy with no session. The only way this could possibly happen is if sessions were once cleaned up (MagmaSession cleanUp) which becomes them all to nil. The proxies in the image at that time now suddenly reference nil instead of their session.
Without a session, materialization cannot succeed, these proxy's are useless. The proxy does not check for a nil session and therefore, the resulting DNU results in the classic "non-debuggerable situation".
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087592.h...
which is a Squeak bug introduced in 3.8 (it didn't occur in 3.7) that results in the orgy of spawning Processes instead of a debugger.
This image needs to be cleaned up and the problem should go away, but obviously something better needs to be done with the #cleanUp method so this situation doesn't happen again. Honestly, we may just need a #fixTemps somewhere in the Magma code for the sessions to be properly garbage collected, and then the #cleanUp probably won't even be needed anymore...
Regards, Chris
----- Original Message ---- From: "goran@krampe.se" goran@krampe.se To: magma@lists.squeakfoundation.org Sent: Wednesday, October 4, 2006 1:04:34 PM Subject: Processes gone wild bug isolated
Hi Chris!
Ok, Magnus managed to isolate the "Processes going wild"-bug. To make sure you get a chance to debug this we simply froze the whole Gjallar installation! :) It is available here:
http://gjallar.krampe.se/gjallar_before_clean_image_small.zip (53 Mb)
Mmm, that is for windows, eh, well - it probably can be opened on another box too.
Here follows the step by step instruction from Magnus: ------------ To reprocude the problem where Gjallar runs an infinite(?) loop¾spawning thousands of processes, follow these instructions.
1. Unzip the¾53Mb file.
2. Open the image: "Squeak3.8-6665-gjallar.6.image" (Wait for the web server to start)
3. In a web browser navigate to: http://localhost:8081/seaside/Gjallar
4. Log in as: root/goldfish
5. Proceed over the break points at: ¾¾¾ - Q2RootUser(Q2User)>>tabelCaseForm ¾¾¾ - Q2RootUser(Q2FullAccessUser)>>processes
6. When proceeding over Q2Model>>processes, new processes (threads) will be spawned like crazy...
7. To stop the creation of new processes. ¾¾¾ - In the Workspace named "Doits", run the code: ¾¾¾ (Process allInstances select: [:p | p isSuspended]) do: [:pp | pp terminate; install: nil ] ¾¾¾ - Repeat (hit alt-d over and over) until a new debugger window pops up (MessageNotUnderstood: UndefinedObject>>realObjectFor:)
8. When all suspended processes are killed, navigate to http://localhost:8081/seaside/Gjallar, and log is as balder/balder. This works fine, because this user will use the Q2User instance variable for self processes. The root user uses self model processes.
/ Magnus _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi Chris!
As always - nice with such fast responses!
Chris Muller chris@funkyobjects.org wrote:
Hi Göran, thanks for the image. It really does make the difference between total speculation and finding a plausible explanation.
As it turns out, the root Q2User's model's processes is a proxy with no session. The only way this could possibly happen is if sessions were once cleaned up (MagmaSession cleanUp) which becomes them all to nil. The proxies in the image at that time now suddenly reference nil instead of their session.
Without a session, materialization cannot succeed, these proxy's are useless. The proxy does not check for a nil session and therefore, the resulting DNU results in the classic "non-debuggerable situation".
http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087592.h...
which is a Squeak bug introduced in 3.8 (it didn't occur in 3.7) that results in the orgy of spawning Processes instead of a debugger.
This image needs to be cleaned up and the problem should go away, but obviously something better needs to be done with the #cleanUp method so this situation doesn't happen again.
Ok, so the next step for us is to figure out why this Q2User refers to a Q2Model that has an "old" proxy in it, right? I have a suspicion about that and will check it. Thanks!
regards, Göran
PS. Only discovered yesterday that serverloader .23 was available at the Magma repo but not at the MagmaTester repo which I have been tracking. Oh well, you did tell us. :)
magma@lists.squeakfoundation.org