Re: [Pharo-project] 12186 image quit problem
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.
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 <marcus.denker@inria.fr>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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is reproducible for me if I do: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfExternalWebBrowser'; load. (Smalltalk at: #ConfigurationOfExternalWebBrowser) load Find the error log attached. Alex 2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
This is reproducible for me if I do:
Gofer new  squeaksource: 'MetacelloRepository';  package: 'ConfigurationOfExternalWebBrowser';  load.
 (Smalltalk at: #ConfigurationOfExternalWebBrowser) load
Find the error log attached.
During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well
Alex
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Fri, 8 Oct 2010, Igor Stasenko wrote:
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>: This is reproducible for me if I do:
Gofer new  squeaksource: 'MetacelloRepository';  package: 'ConfigurationOfExternalWebBrowser';  load.
 (Smalltalk at: #ConfigurationOfExternalWebBrowser) load
Find the error log attached.
During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well It should be FFI-Pools.eem.2. Levente
Alex
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Levente Uzonyi <leves@elte.hu>:
On Fri, 8 Oct 2010, Igor Stasenko wrote:
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>: This is reproducible for me if I do:
Gofer new  squeaksource: 'MetacelloRepository';  package: 'ConfigurationOfExternalWebBrowser';  load.
 (Smalltalk at: #ConfigurationOfExternalWebBrowser) load
Find the error log attached.
During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well
It should be FFI-Pools.eem.2.
whatever.. config fails to locate this file. Its not my fault :)
Levente
Alex
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Fri, 8 Oct 2010, Igor Stasenko wrote:
2010/10/8 Levente Uzonyi <leves@elte.hu>: On Fri, 8 Oct 2010, Igor Stasenko wrote:
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>: This is reproducible for me if I do:
Gofer new  squeaksource: 'MetacelloRepository';  package: 'ConfigurationOfExternalWebBrowser';  load.
 (Smalltalk at: #ConfigurationOfExternalWebBrowser) load
Find the error log attached.
During load , it says that FFI-Pools.em.2 does not exists. But i picked ar.1 version and continued, that save&quit everything works well
It should be FFI-Pools.eem.2.
whatever.. config fails to locate this file. Its not my fault :) Maybe I wasn't clear. I tried to say that the configuration should be fixed, because it contains a typo. FFI-Pools.em.2 doesn't exist, it should be FFI-Pools.eem.2. Levente
Levente
Alex
2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza@blobworks.com] Sent: Friday, October 08, 2010 5:06 AM To: Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza@blobworks.com] Sent: Friday, October 08, 2010 5:06 AM To: Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard [adi@netstyle.ch] Sent: Friday, October 08, 2010 8:21 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza@blobworks.com] Sent: Friday, October 08, 2010 5:06 AM To: Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard [adi@netstyle.ch] Sent: Friday, October 08, 2010 8:21 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza@blobworks.com] Sent: Friday, October 08, 2010 5:06 AM To: Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Friday, October 08, 2010 9:44 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard [adi@netstyle.ch] Sent: Friday, October 08, 2010 8:21 AM To: Pharo-project@lists.gforge.inria.fr 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Alexander LazareviÄ [laza@blobworks.com] Sent: Friday, October 08, 2010 5:06 AM To: Pharo-project@lists.gforge.inria.fr 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 <pavel.krivanek@gmail.com>:
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 <marcus.denker@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Levente Uzonyi <leves@elte.hu>:
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.
I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal. http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html Alex
.. or you have a very recent OSProcessPlugin and activate SIGUSR1 2010/10/8 Alexander LazareviÄ <laza@blobworks.com>:
2010/10/8 Levente Uzonyi <leves@elte.hu>:
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.
I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html
Alex
On Fri, 8 Oct 2010, Alexander LazareviÄ wrote:
2010/10/8 Levente Uzonyi <leves@elte.hu>:
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.
I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html
Indeed. Thanks for clarifying. Levente
Alex
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Not sure I follow. Is this saying that one chooses between the default console output and printAllStacks(), or is it making printAllStacks() happen in response to the signal and leaving the usual output in place too? I guess another option might be that all stacks get printed instead of just the active process?? ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves@elte.hu] Sent: Friday, October 08, 2010 12:12 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem On Fri, 8 Oct 2010, Alexander LazareviÄ wrote:
2010/10/8 Levente Uzonyi <leves@elte.hu>:
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.
I think it's like that: On a vanilla/standard unix vm SIGUSR1 just terminates the vm. With a cog vm you trigger a printAllStacks with that Signal.
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-July/152001.html
Indeed. Thanks for clarifying. Levente
Alex
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Marcus, is that really all what happened between 12172 and 12186? update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker@inria.fr>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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pavel, You say it "hangs without error." Squeak fails silently in many situations in the vms and the image, so a failure to provide diagnostic info is not a new thought, but this sounds like a deadlock between finalization and something else important - at least that is what I *think* I am reading. There might not be an error to report. Not to single out Sig, but has he not been working on finalization? I've debugged a few deadlocks over time, usually less dramatic that this, but my first step would be to find the processes that are involved. In terms of callstacks, all but the active process will be waiting on a semaphore; the first step is to find the ones doing that inside of critical sections. Typically one of the critical sections is "too big." The remedy can be to break the section into a smaller blocks, grabbing the shared resource(s) only needed. Other times, I have found it necessary/expedient to add a "third process" that moves objects or signals from one thread to the other. It can also be that one mutex is doing the work of two or more, though that usually arises in connection management where one protects a map of what goes where and then individually protects the connections (so it's 1+n mutexes rather than two of them - I doubt it applies here). Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Pavel Krivanek [pavel.krivanek@gmail.com] Sent: Friday, October 08, 2010 6:39 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem Hi Marcus, is that really all what happened between 12172 and 12186? update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel On Fri, Oct 8, 2010 at 10:49 AM, Marcus Denker <marcus.denker@inria.fr<mailto:marcus.denker@inria.fr>> 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 Pharo-project@lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing: WeakArray restartFinalizationProcess. it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore. -- Best regards, Igor Stasenko AKA sig.
also, it 'hangs' because InputEventSensor>>shutdown runs before MCMethodDefinition>>shutdown So, you can't interrupt it with alt-. , because nobody handles it anymore. On 8 October 2010 18:06, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me... -- Pavel
On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me...
-- Pavel
with the MCMethodDefinition>>shutdown hack it work well -- Pavel
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me... -- Pavel
with the MCMethodDefinition>>shutdown hack it work well
so, at least we know what causing it. Now i wonder, what may cause that WeakArray classPool at: #FinalizationLock get locked by some other process and not released anymore?
-- Pavel
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Fri, Oct 8, 2010 at 7:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <pavel.krivanek@gmail.com
wrote:
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I
cannot
build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me... -- Pavel
with the MCMethodDefinition>>shutdown hack it work well
so, at least we know what causing it.
Now i wonder, what may cause that WeakArray classPool at: #FinalizationLock get locked by some other process and not released anymore?
if I replace critical:ifError: by critical:ifLocked: in WeakArray >> removeWeakDependent:, it shows that it is really locked. I can reproduce it everytime. Any idea how can I determine who locked it? -- Pavel
On Sun, Oct 10, 2010 at 10:09 AM, Pavel Krivanek <pavel.krivanek@gmail.com>wrote:
On Fri, Oct 8, 2010 at 7:40 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
On Fri, Oct 8, 2010 at 7:15 PM, Pavel Krivanek <
pavel.krivanek@gmail.com>
wrote:
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com>
wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I
cannot
build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me... -- Pavel
with the MCMethodDefinition>>shutdown hack it work well
so, at least we know what causing it.
Now i wonder, what may cause that WeakArray classPool at: #FinalizationLock get locked by some other process and not released anymore?
if I replace critical:ifError: by critical:ifLocked: in WeakArray >> removeWeakDependent:, it shows that it is really locked. I can reproduce it everytime. Any idea how can I determine who locked it?
-- Pavel
It collides with HostSystemMenusProxy class >> unregister this is the call stack: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakRegistry>>protected: WeakRegistry>>remove:ifAbsent: HostSystemMenusProxy class>>unregister: HostSystemMenusProxy>>unregister HostSystemMenusProxy>>destroyEveryThing [self destroyEveryThing] in HostSystemMenusProxy>>finalize BlockClosure>>on:do: BlockClosure>>ifError: HostSystemMenusProxy>>finalize WeakFinalizerItem>>finalizeValues [:finItem | finItem finalizeValues] in [valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues]] in WeakRegistry>>finalizeValues WeakIdentityKeyDictionary(WeakKeyDictionary)>>expiredValuesDo: [valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues]] in WeakRegistry>>finalizeValues [mutuallyExcludedBlock value] in [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: BlockClosure>>on:do: BlockClosure>>ifError: [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakRegistry>>protected: WeakRegistry>>finalizeValues [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]] in [WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] in WeakArray class>>finalizationProcess WeakArray(SequenceableCollection)>>do: [WeakFinalizationList checkTestPair. FinalizationDependents do: [:weakDependent | weakDependent ifNotNil: [weakDependent finalizeValues]]] in WeakArray class>>finalizationProcess [mutuallyExcludedBlock value] in [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: BlockClosure>>on:do: BlockClosure>>ifError: [blockValue := [mutuallyExcludedBlock value] ifError: [:msg :rcvr | hasError := true. errMsg := msg. errRcvr := rcvr]] in Semaphore>>critical:ifError: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: Semaphore>>critical:ifError: WeakArray class>>finalizationProcess [self finalizationProcess] in WeakArray class>>restartFinalizationProcess [self value. Processor terminateActive] in BlockClosure>>newProcess -- Pavel
OKay, now i see what the problem: <weak registry protected> <finalize items> <HostSystemMenusProxy>>finalize> .... <HostSystemMenusProxy class>>unregister> <weak registry protected> In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock. Then following piece: WeakRegistry>>finalizeValues self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. should be rewritten as: | expired | expired := OrderedCollection new. self protected: [ valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] ]. expired do: #finalizeValues. But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless. -- Best regards, Igor Stasenko AKA sig.
Sig, Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, October 10, 2010 7:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem OKay, now i see what the problem: <weak registry protected> <finalize items> <HostSystemMenusProxy>>finalize> .... <HostSystemMenusProxy class>>unregister> <weak registry protected> In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock. Then following piece: WeakRegistry>>finalizeValues self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. should be rewritten as: | expired | expired := OrderedCollection new. self protected: [ valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] ]. expired do: #finalizeValues. But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless. -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
Have you thought about using a Mutex? Â Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Â Semaphores are wonderful for #wait/#signal. Â But for #critical:, I use Mutex which won't deadlock a thread with itself.
yes, i thought about it. It wont help in this situation, because if you start modifying dictionary inside a loop, which scanning its elements (like #do:) you'll have very unpleasant results. All HostSystemMenusProxy doing during #finalize is removing itself from weakregistry (which is complete nonsense, since weak registry cleaning itself from dead stuff anyways). So, self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ]. actually triggers a bug/mistake in HostSystemMenusProxy , which leads to deadlock. :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Sunday, October 10, 2010 7:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem
OKay, now i see what the problem:
<weak registry protected> Â <finalize items> Â Â Â <HostSystemMenusProxy>>finalize> Â Â Â Â Â Â .... Â Â Â Â Â Â <HostSystemMenusProxy class>>unregister> Â Â Â Â Â Â Â <weak registry protected>
In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock.
Then following piece:
WeakRegistry>>finalizeValues
self protected: [     valueDictionary expiredValuesDo: [:finItem |         finItem finalizeValues  ].  ].
should be rewritten as:
| expired | expired := OrderedCollection new. self protected: [ Â Â Â Â valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] Â ]. expired do: #finalizeValues.
But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Ok, I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3091 <http://code.google.com/p/pharo/issues/detail?id=3091>The patch works for me, Thank you Igor. Cheers, -- Pavel On Sun, Oct 10, 2010 at 6:46 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 10 October 2010 17:40, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Sig,
Have you thought about using a Mutex? Maybe I'm missing something in life, but long ago I decided the #forMutualExclusion is *beyond* private. Semaphores are wonderful for #wait/#signal. But for #critical:, I use Mutex which won't deadlock a thread with itself.
yes, i thought about it. It wont help in this situation, because if you start modifying dictionary inside a loop, which scanning its elements (like #do:) you'll have very unpleasant results.
All HostSystemMenusProxy doing during #finalize is removing itself from weakregistry (which is complete nonsense, since weak registry cleaning itself from dead stuff anyways). So, self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ].
actually triggers a bug/mistake in HostSystemMenusProxy , which leads to deadlock. :)
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [ siguctua@gmail.com] Sent: Sunday, October 10, 2010 7:56 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 12186 image quit problem
OKay, now i see what the problem:
<weak registry protected> <finalize items> <HostSystemMenusProxy>>finalize> .... <HostSystemMenusProxy class>>unregister> <weak registry protected>
In my WeakRegistry, a #finalize message sent while registry semaphore locked, so, in case if object in #finalize trying to manipulate with registry then it going to deadlock.
Then following piece:
WeakRegistry>>finalizeValues
self protected: [ valueDictionary expiredValuesDo: [:finItem | finItem finalizeValues ]. ].
should be rewritten as:
| expired | expired := OrderedCollection new. self protected: [ valueDictionary expiredValuesDo: [:finItem | expired add: finItem ] ]. expired do: #finalizeValues.
But either way, HostSystemMenusProxy should not attempt remove itself from registry during #finalize (and causing a deadlock), since its pointless.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
On Fri, Oct 8, 2010 at 5:06 PM, Igor Stasenko <siguctua@gmail.com> wrote:
2010/10/8 Pavel Krivanek <pavel.krivanek@gmail.com>:
Hi Marcus, is that really all what happened between 12172 and 12186?
update12186 Issue 3071: fixing timestamp tests Issue 3068: Non portable SmalltalkImage>>platformName deprecationWarning Issue 3063: removing explain Issue 3039: There should not be any configuration on Core It doesn't explain the problems with VM versions and in 12186 I cannot build the PharoKernel (it hangs without error in unload phase) -- Pavel
please , tell me if it keep hanging after you doing:
WeakArray restartFinalizationProcess.
it seems like a deadlock with WeakArray's FinalizationLock or FinalizationSemaphore.
it hangs for me...
hmm. strange. i can't reproduce this anymore (even after taking fresh 12186 image).
-- Pavel _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
participants (7)
-
Adrian Lienhard -
Alexander LazareviÄ -
Igor Stasenko -
Levente Uzonyi -
Marcus Denker -
Pavel Krivanek -
Schwab,Wilhelm K