Levente, This was several years ago in the Windows VM. I recall both shouting at the rain with no echo at the time, and years later seeing something very close to what I had done. At the time, printAllStacks() existed (which was why I had a prayer of succeeding), but produced a very jumbled mess with linefeeds in the wrong places. I did something with adding a feed or two outside of a loop over semaphores and then adding conditionals to the feeds inside the loop. More or less; it's been a while.
Great news that the vm offers a ready way to trigger printAllStacks(); there are times when it is VERY useful, and if I'm right about what started this discussion, this will be one of them. It can't hurt much if I'm wrong - the double #critical:/#wait pattern would simply not appear and we would then know something that isn't causing it :) About SIGUSR1 on Linux, is the idea to open a terminal and send kill with SIGUSR 1 to the correct process ID? Where does the dump go? I'm guessing it goes to stdout of the vm, not to the terminal that sent the signal?? That would mean that one would need to have run the vm from a terminal or otherwise have arranged in advance to capture the output. So far at least, I tend to use a terminal to launch Pharo only when I expect to want trace info (such as when debugging one of my numerical .so functions) or when I have a reproducible badness (which this appears to be). Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Levente Uzonyi [[email protected]] Sent: Friday, October 08, 2010 9:44 AM To: [email protected] Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Schwab,Wilhelm K wrote: > That's good to know. It probably should be a lot easier than that. At least > in the Windows vm, there is/was a debug menu (part of the vm's system menu) > that would dump the stack for the active process; I hacked it to dump all of > them rather than just one, fixed printAllStacks() along the way, and found my > problem. Think of an end user machine; you don't want to have to, or might > not be able to, install development tools just to get this type of basic > information. It might simply be a way of ruling out problems, but it could > be very important. It's a lot easier than that. On windows just select the appropriate menu item "Dump all processes" instead of "Dump call stack". On un*x you can send SIGUSR1 to the process of the VM to make it print all stacks. IIRC Cog uses this signal for another purpose, so it doesn't work with Cog. What was the problem with printAllStacks() that you had to fix? Levente > > > ________________________________________ > From: [email protected] > [[email protected]] On Behalf Of Adrian Lienhard > [[email protected]] > Sent: Friday, October 08, 2010 8:21 AM > To: [email protected] > Subject: Re: [Pharo-project] 12186 image quit problem > > You can attach gdb to the VM and then call printAllStacks(). > > HTH, > Adrian > > On Oct 8, 2010, at 14:07 , Schwab,Wilhelm K wrote: > >> Do you have access to anything that will dump the callstacks for "all" >> processes? One of my first encounters with the Squeak update streams was >> trying to provide patches to the dump code... Similar features appeared >> years later, I suspect unrelated to my efforts. What I did was hack the VM >> such that the dump (on the vm menu) gave all (non-dead IIRC) processes >> rather than just that for the active process; for it to be readable required >> some changes to when the dump adds a line feed. >> >> Seeing which threads are waiting on semaphores wrapped in critical sections >> can be a huge help in finding deadlocks. Get it to lock up, then ask the vm >> for the dump and look for the offenders. If we don't have this, we should. >> >> Bill >> >> >> >> ________________________________________ >> From: [email protected] >> [[email protected]] On Behalf Of Alexander >> Lazarević [[email protected]] >> Sent: Friday, October 08, 2010 5:06 AM >> To: [email protected] >> Subject: Re: [Pharo-project] 12186 image quit problem >> >> Just when I was about to test drive Torstens configuration of >> ExternalWebBrowser, the image hangs somewhere while loading. I'm able >> to abort it and find myself in some ensure block of an crticial >> section of WeakArray finalization?! Trying to quit just hangs the >> image for good. >> BTW, this is on Windows. >> >> Alex >> >> 2010/10/8 Pavel Krivanek <[email protected]>: >>> Strange... >>> Linux VM 4.0.3.2202 from squeakvm.org worked well and your prebuilt image >>> works with all this three virtual machines. Any idea why? >>> -- Pavel >>> >>> On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <[email protected]> >>> wrote: >>>> >>>> On Oct 8, 2010, at 10:39 AM, Pavel Krivanek wrote: >>>> >>>>> Hmm, this is the result for Linux and >>>>> cogvm 3.9-7 and pharovm 3.10-3 >>>>> >>>>> >>>> >>>> can you try: >>>> >>>> https://gforge.inria.fr/frs/download.php/27589/PharoCore-1.2-12186.zip >>>> >>>> >>>> -- >>>> Marcus Denker -- http://www.marcusdenker.de >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
