Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
On 20 May 2011 15:25, Tudor Girba tudor@tudorgirba.com wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
On 20 May 2011 16:57, Igor Stasenko siguctua@gmail.com wrote:
On 20 May 2011 15:25, Tudor Girba tudor@tudorgirba.com wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
oh.. wait.. sorry. i was confused with 'kbytes' i thought i was 'bytes' 2507424 kbytes = 2507424 * 1024 bytes, so its more than 2G
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
-- Best regards, Igor Stasenko AKA sig.
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers, - Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
Hi,
I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :).
Would it be possible to find some resolution on it?
Cheers, Doru
On 20 May 2011, at 17:08, Andreas Raab wrote:
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers,
- Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
-- www.tudorgirba.com
"Every thing has its own flow."
On 5/20/2011 17:19, Tudor Girba wrote:
I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :).
We are nowhere on this issue. I should add that with OpenQwaq / Teleplace we've been running large images (300-500MB) all the time on Windows with no problems. And I am not at all convinced that this is even a VM issue; I find it more likely that there might be some platform dependency that causes some code to go wrong and actually eat all available memory. My comment below was just pointing out that your OS memory configuration looks perfectly normal.
What I would do in your situation is to run the code that created this image directly under Windows, then save and try to start it up again. If you get an error when you run the code, you will be able to tell whether it's a memory problem or not. If the image saves and starts fine again on Windows, you can be pretty sure that it's not a VM problem but some platform dependency. And then you might try to move the image to a Mac to see if that teaches you anything.
Cheers, - Andreas
Would it be possible to find some resolution on it?
Cheers, Doru
On 20 May 2011, at 17:08, Andreas Raab wrote:
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers,
- Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible.
You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
-- www.tudorgirba.com
"Every thing has its own flow."
Hi Andreas,
On 20 May 2011, at 17:44, Andreas Raab wrote:
On 5/20/2011 17:19, Tudor Girba wrote:
I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :).
We are nowhere on this issue. I should add that with OpenQwaq / Teleplace we've been running large images (300-500MB) all the time on Windows with no problems.
I also thought that this cannot be that obvious of a problem, because otherwise people would have stumbled over it before.
And I am not at all convinced that this is even a VM issue; I find it more likely that there might be some platform dependency that causes some code to go wrong and actually eat all available memory. My comment below was just pointing out that your OS memory configuration looks perfectly normal.
I understood that. I just wanted to pick the discussion up and see what can be done.
What I would do in your situation is to run the code that created this image directly under Windows, then save and try to start it up again. If you get an error when you run the code, you will be able to tell whether it's a memory problem or not. If the image saves and starts fine again on Windows, you can be pretty sure that it's not a VM problem but some platform dependency. And then you might try to move the image to a Mac to see if that teaches you anything.
I tried the followings: - Build the image on Windows 7, save, and open on Windows 7 ==> out of memory message - Build the image on Windows 7, save, and open on OS X 10.6 ==> fine - Build the image on OS X 10.6, save, and open on Windows 7 ==> out of memory message
To me, it looks like a Windows-related problem.
A problem is that I do not have a Windows machine on which I can test this too much, but when I tried, I could reproduce it repeatedly:
1. Take a Moose image: http://ci.moosetechnology.org/job/moose-latest-dev/375/artifact/moose/*zip*/... 2. Run in a Workspace (it takes a while): 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] This will basically create some 850000 objects and will get the image to some 400+MB 3. Save and quit the image 4. Reopen it
Cheers, Doru
Cheers,
- Andreas
Would it be possible to find some resolution on it?
Cheers, Doru
On 20 May 2011, at 17:08, Andreas Raab wrote:
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers,
- Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
On Wed, 18 May 2011, Tudor Girba wrote:
snip
> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z...
I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
Levente
snip
-- www.tudorgirba.com
"Being happy is a matter of choice."
-- www.tudorgirba.com
"Every thing has its own flow."
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
Thanks doru. Igor tried to do some experiences creating large images on mac and opening them on windows last friday. So he will certainly have a look at it again
Stef
On May 21, 2011, at 7:13 PM, Tudor Girba wrote:
Hi Andreas,
On 20 May 2011, at 17:44, Andreas Raab wrote:
On 5/20/2011 17:19, Tudor Girba wrote:
I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :).
We are nowhere on this issue. I should add that with OpenQwaq / Teleplace we've been running large images (300-500MB) all the time on Windows with no problems.
I also thought that this cannot be that obvious of a problem, because otherwise people would have stumbled over it before.
And I am not at all convinced that this is even a VM issue; I find it more likely that there might be some platform dependency that causes some code to go wrong and actually eat all available memory. My comment below was just pointing out that your OS memory configuration looks perfectly normal.
I understood that. I just wanted to pick the discussion up and see what can be done.
What I would do in your situation is to run the code that created this image directly under Windows, then save and try to start it up again. If you get an error when you run the code, you will be able to tell whether it's a memory problem or not. If the image saves and starts fine again on Windows, you can be pretty sure that it's not a VM problem but some platform dependency. And then you might try to move the image to a Mac to see if that teaches you anything.
I tried the followings:
- Build the image on Windows 7, save, and open on Windows 7 ==> out of memory message
- Build the image on Windows 7, save, and open on OS X 10.6 ==> fine
- Build the image on OS X 10.6, save, and open on Windows 7 ==> out of memory message
To me, it looks like a Windows-related problem.
A problem is that I do not have a Windows machine on which I can test this too much, but when I tried, I could reproduce it repeatedly:
- Take a Moose image:
http://ci.moosetechnology.org/job/moose-latest-dev/375/artifact/moose/*zip*/... 2. Run in a Workspace (it takes a while): 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] This will basically create some 850000 objects and will get the image to some 400+MB 3. Save and quit the image 4. Reopen it
Cheers, Doru
Cheers,
- Andreas
Would it be possible to find some resolution on it?
Cheers, Doru
On 20 May 2011, at 17:08, Andreas Raab wrote:
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers,
- Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
> On Wed, 18 May 2011, Tudor Girba wrote: > > snip > >> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. > You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z... I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
> Levente >
> snip
www.tudorgirba.com
"Being happy is a matter of choice."
-- www.tudorgirba.com
"Every thing has its own flow."
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
Hi again,
Just an update on this issue.
It looks like it is an issue with the memory allocation in the Cog VM on Windows. Igor did a good job to fix the issue and now large images can be opened again. The fixes are in his branch.
Igor, could you provide more technical details?
I think it is an issue that should be taken seriously and integrated in the main branch.
Cheers, Doru
On 21 May 2011, at 19:13, Tudor Girba wrote:
Hi Andreas,
On 20 May 2011, at 17:44, Andreas Raab wrote:
On 5/20/2011 17:19, Tudor Girba wrote:
I am not sure I understand where we are on this issue. I will say it again that I find it to be critical to be able to work with images that are not small :).
We are nowhere on this issue. I should add that with OpenQwaq / Teleplace we've been running large images (300-500MB) all the time on Windows with no problems.
I also thought that this cannot be that obvious of a problem, because otherwise people would have stumbled over it before.
And I am not at all convinced that this is even a VM issue; I find it more likely that there might be some platform dependency that causes some code to go wrong and actually eat all available memory. My comment below was just pointing out that your OS memory configuration looks perfectly normal.
I understood that. I just wanted to pick the discussion up and see what can be done.
What I would do in your situation is to run the code that created this image directly under Windows, then save and try to start it up again. If you get an error when you run the code, you will be able to tell whether it's a memory problem or not. If the image saves and starts fine again on Windows, you can be pretty sure that it's not a VM problem but some platform dependency. And then you might try to move the image to a Mac to see if that teaches you anything.
I tried the followings:
- Build the image on Windows 7, save, and open on Windows 7 ==> out of memory message
- Build the image on Windows 7, save, and open on OS X 10.6 ==> fine
- Build the image on OS X 10.6, save, and open on Windows 7 ==> out of memory message
To me, it looks like a Windows-related problem.
A problem is that I do not have a Windows machine on which I can test this too much, but when I tried, I could reproduce it repeatedly:
- Take a Moose image:
http://ci.moosetechnology.org/job/moose-latest-dev/375/artifact/moose/*zip*/... 2. Run in a Workspace (it takes a while): 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ] This will basically create some 850000 objects and will get the image to some 400+MB 3. Save and quit the image 4. Reopen it
Cheers, Doru
Cheers,
- Andreas
Would it be possible to find some resolution on it?
Cheers, Doru
On 20 May 2011, at 17:08, Andreas Raab wrote:
On 5/20/2011 16:57, Igor Stasenko wrote:
Here an excert from crash.dmp:
Memory Information (upon launch): Physical Memory Size: 4194303 kbytes Physical Memory Free: 2507424 kbytes Page File Size: 4194303 kbytes Page File Free: 4194303 kbytes Virtual Memory Size: 2097024 kbytes Virtual Memory Free: 2030280 kbytes Memory Load: 59 percent
this is strange. Of course, with sizes like above , it cannot fit into memory.
Nothing strange about it. Standard 4GB Ram configuration with about 2GB available.
Cheers,
- Andreas
Hi,
On 18 May 2011, at 18:07, Levente Uzonyi wrote:
> On Wed, 18 May 2011, Tudor Girba wrote: > > snip > >> I tried with several versions of Cog including the latest ones (on both platforms) and I got the same result. I did not try with an interpreter VM because I only have Cog images around (based on Pharo 1.2) and they are not compatible. > You can use this interpreter vm to open cog images: http://leves.web.elte.hu/squeak/SqueakVM-Win32-4.4.9-2358-non-official-bin.z... I tried with this VM, but it crashes with the attached error.
In any case, if someone wants to reproduce it, here is an image to play with: http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
Cheers, Doru
> Levente >
> snip
www.tudorgirba.com
"Being happy is a matter of choice."
-- www.tudorgirba.com
"Every thing has its own flow."
-- www.tudorgirba.com
"If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
-- www.tudorgirba.com
"Every thing should have the right to be different."
On 27 June 2011 20:08, Tudor Girba tudor@tudorgirba.com wrote:
Hi again,
Just an update on this issue.
It looks like it is an issue with the memory allocation in the Cog VM on Windows. Igor did a good job to fix the issue and now large images can be opened again. The fixes are in his branch.
Except that i didn't uploaded new version yet. Will do that tomorrow.
Igor, could you provide more technical details?
yes i added the issue to cog tracker:
http://code.google.com/p/cog/issues/detail?id=46
I think it is an issue that should be taken seriously and integrated in the main branch.
Cheers, Doru
On 21 May 2011, at 19:13, Tudor Girba wrote:
Thanks, Igor.
Doru
On 27 Jun 2011, at 23:07, Igor Stasenko wrote:
On 27 June 2011 20:08, Tudor Girba tudor@tudorgirba.com wrote:
Hi again,
Just an update on this issue.
It looks like it is an issue with the memory allocation in the Cog VM on Windows. Igor did a good job to fix the issue and now large images can be opened again. The fixes are in his branch.
Except that i didn't uploaded new version yet. Will do that tomorrow.
Igor, could you provide more technical details?
yes i added the issue to cog tracker:
http://code.google.com/p/cog/issues/detail?id=46
I think it is an issue that should be taken seriously and integrated in the main branch.
Cheers, Doru
On 21 May 2011, at 19:13, Tudor Girba wrote:
-- Best regards, Igor Stasenko AKA sig.
-- www.tudorgirba.com
"Every now and then stop and ask yourself if the war you're fighting is the right one."
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Igor Stasenko -
stephane ducasse -
Tudor Girba