Crash on saving with Monticello

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Crash on saving with Monticello

Alexandre Bergel
Hi!

Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
Are we the only one to experience this?

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Mariano Martinez Peck


On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
Are we the only one to experience this?


yes, probably the UUID known problem. Just renaming / removing the plugin may work.
Are they in Ubuntu/debian?

Please let us know if we should do this for the PharoOneClick image.

cheers

mariano
 
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Guillermo Polito
I use CogVm (I compiled it myself a few months ago, so it isn't the last version) and it's working ok for me.

On Tue, Dec 28, 2010 at 10:09 AM, Mariano Martinez Peck <[hidden email]> wrote:


On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
Are we the only one to experience this?


yes, probably the UUID known problem. Just renaming / removing the plugin may work.
Are they in Ubuntu/debian?

Please let us know if we should do this for the PharoOneClick image.

cheers

mariano
 
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.








Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Schwab,Wilhelm K
With all the trouble over this with time, it seemed reasonable to try to trigger it while I had the one-click in front of me.  I have the one-click 1.2 from the Hudson server (#42??) running on Ubuntu 10.4.  So far, I have not been able to trigger it by creating a package and saving another.  Is inspecting UUID new enough?  Is there anything else I should try?




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Guillermo Polito [[hidden email]]
Sent: Tuesday, December 28, 2010 8:15 AM
To: [hidden email]
Subject: Re: [Pharo-project] Crash on saving with Monticello

I use CogVm (I compiled it myself a few months ago, so it isn't the last version) and it's working ok for me.

On Tue, Dec 28, 2010 at 10:09 AM, Mariano Martinez Peck <[hidden email]<mailto:[hidden email]>> wrote:


On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]<mailto:[hidden email]>> wrote:
Hi!

Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
Are we the only one to experience this?


yes, probably the UUID known problem. Just renaming / removing the plugin may work.
Are they in Ubuntu/debian?

Please let us know if we should do this for the PharoOneClick image.

cheers

mariano

Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.









Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Alexandre Bergel
In reply to this post by Mariano Martinez Peck
Hi!

Sorry for the late answer. The student is now in my office and there is indeed a problem.
UUIDPlugin is not present on his harddisk. Maybe built in the VM.

I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?

Cheers,
Alexandre


On 28 Dec 2010, at 10:09, Mariano Martinez Peck wrote:

>
>
> On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]> wrote:
> Hi!
>
> Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
> Are we the only one to experience this?
>
>
> yes, probably the UUID known problem. Just renaming / removing the plugin may work.
> Are they in Ubuntu/debian?
>
> Please let us know if we should do this for the PharoOneClick image.
>
> cheers
>
> mariano
>  
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Philippe Marschall-2
On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
> Hi!
>
> Sorry for the late answer. The student is now in my office and there is indeed a problem.
> UUIDPlugin is not present on his harddisk. Maybe built in the VM.
>
> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?

Has been known for two years, shouldn't happen, nobody cares.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Alexandre Bergel
>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
>
> Has been known for two years, shouldn't happen, nobody cares.


One student of mine works with Ubuntu and the last Pharo 1.2 one click image, and he does care. He couldn't do a save in Monticello before I remove the call to the primitive.

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

David T. Lewis
In reply to this post by Philippe Marschall-2
On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote:

> On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
> > Hi!
> >
> > Sorry for the late answer. The student is now in my office and there is indeed a problem.
> > UUIDPlugin is not present on his harddisk. Maybe built in the VM.
> >
> > I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
>
> Has been known for two years, shouldn't happen, nobody cares.
>

Huh ?!?!? What do you mean "nobody cares"?

We are apparently now facing two *different* bugs in two different
sets of Linux distributions. It's documented here:

  http://bugs.squeak.org/view.php?id=7358

The only solution I can suggest is to get rid of the UUIDPlugin on
unix VMs until the various Linux distros get this fixed. If anyone
has a better solution *please* speak up. If you don't know how to
fix it, well join the club but don't say that nobody cares.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Philippe Marschall-2-3
On 03.01.2011 16:42, David T. Lewis wrote:

> On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote:
>> On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
>>> Hi!
>>>
>>> Sorry for the late answer. The student is now in my office and there is indeed a problem.
>>> UUIDPlugin is not present on his harddisk. Maybe built in the VM.
>>>
>>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
>>
>> Has been known for two years, shouldn't happen, nobody cares.
>>
>
> Huh ?!?!? What do you mean "nobody cares"?

Nodby cares enough to get to the bottom of it and fix it once and for
all. And yes, that includes me. It's just an observation. So if this is
really critical for somebody then he'll have to fix it himself.
Reporting the same bug again won't make a difference. That's just how
open source is.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

David T. Lewis
On Mon, Jan 03, 2011 at 09:14:47PM +0100, Philippe Marschall wrote:

> On 03.01.2011 16:42, David T. Lewis wrote:
> > On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote:
> >> On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
> >>> Hi!
> >>>
> >>> Sorry for the late answer. The student is now in my office and there is indeed a problem.
> >>> UUIDPlugin is not present on his harddisk. Maybe built in the VM.
> >>>
> >>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
> >>
> >> Has been known for two years, shouldn't happen, nobody cares.
> >>
> >
> > Huh ?!?!? What do you mean "nobody cares"?
>
> Nodby cares enough to get to the bottom of it and fix it once and for
> all. And yes, that includes me. It's just an observation. So if this is
> really critical for somebody then he'll have to fix it himself.
> Reporting the same bug again won't make a difference. That's just how
> open source is.
>
> Cheers
> Philippe
>

Yep :)

But I do want to make it clear that it seems the bug is not in
the plugin, it is in the libuuid implementations. We've all been
trying to find workarounds, but unfortunately not with much
success. For a while we could work around it by compiling the
plugin internally (which somehow prevents the bug from being
exposed), but now we have some 64-bit Linux distros that accidentally
left the 32-bit libuuid out of the distro, which prevents the VM
from running if the plugin was compiled internally. I'm sure it
has been fixed in up to date distros, but now we have one set of
Linux users with buggy libuuid libraries, and another set of Linux
users with missing 32-bit libuuid libraries, so somebody is going
to get screwed either way now :-/

I'm sure there must be some way to fix this that we're all missing,
so if anyone wants to look at it with a fresh set of eyes that
would be great.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Mariano Martinez Peck
In reply to this post by Alexandre Bergel


On Mon, Jan 3, 2011 at 3:25 PM, Alexandre Bergel <[hidden email]> wrote:
Hi!

Sorry for the late answer. The student is now in my office and there is indeed a problem.
UUIDPlugin is not present on his harddisk. Maybe built in the VM.

I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?

yes, please. We need to aboid this somehow
 
Alexandre, so you changed from:

primMakeUUID
<primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'>
UUIDGenerator default generateBytes: self forVersion: 4

to:

primMakeUUID
UUIDGenerator default generateBytes: self forVersion: 4.

?


What about changing to:

 primMakeUUID
        self isOSSafeForUUID 
               ifTrue: [ ^ self internalPrimitiveMakeUUID ]
               ifFalse: [^ UUIDGenerator default generateBytes: self forVersion: 4].


isOSSafeForUUID
 "it would be great being able to check wether the OS is 64 bits or not, but I don't know how to ask that from the image"
 ^ Smalltalk os isUnix not

internalPrimitiveMakeUUID
<primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'>


Then....when this is really fixed, we remove all this crap.
Of you agree, I open a ticket.

Cheers

mariano



Cheers,
Alexandre


On 28 Dec 2010, at 10:09, Mariano Martinez Peck wrote:

>
>
> On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]> wrote:
> Hi!
>
> Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
> Are we the only one to experience this?
>
>
> yes, probably the UUID known problem. Just renaming / removing the plugin may work.
> Are they in Ubuntu/debian?
>
> Please let us know if we should do this for the PharoOneClick image.
>
> cheers
>
> mariano
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.







Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Alexandre Bergel
> Alexandre, so you changed from:
>
> primMakeUUID
> <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'>
> UUIDGenerator default generateBytes: self forVersion: 4
>
> to:
>
> primMakeUUID
> UUIDGenerator default generateBytes: self forVersion: 4.
>
> ?

Yes. I was able to save and load from Monticello.

> What about changing to:
>
>  primMakeUUID
>         self isOSSafeForUUID
>                ifTrue: [ ^ self internalPrimitiveMakeUUID ]
>                ifFalse: [^ UUIDGenerator default generateBytes: self forVersion: 4].
>
>
> isOSSafeForUUID
>  "it would be great being able to check wether the OS is 64 bits or not, but I don't know how to ask that from the image"
>  ^ Smalltalk os isUnix not
>
> internalPrimitiveMakeUUID
> <primitive: 'primitiveMakeUUID' module: 'UUIDPlugin'>

I haven't found myself very close to the UUID problem and I do not have a global picture of the problem. If other agree, then I am ok.

Alexandre


> Then....when this is really fixed, we remove all this crap.
> Of you agree, I open a ticket.
>
> Cheers
>
> mariano
>
>
>
> Cheers,
> Alexandre
>
>
> On 28 Dec 2010, at 10:09, Mariano Martinez Peck wrote:
>
> >
> >
> > On Tue, Dec 28, 2010 at 2:00 PM, Alexandre Bergel <[hidden email]> wrote:
> > Hi!
> >
> > Several of my students experience a crash of Pharo when saving with Monticello. They all use linux. I can ask for more detailed description.
> > Are we the only one to experience this?
> >
> >
> > yes, probably the UUID known problem. Just renaming / removing the plugin may work.
> > Are they in Ubuntu/debian?
> >
> > Please let us know if we should do this for the PharoOneClick image.
> >
> > cheers
> >
> > mariano
> >
> > Cheers,
> > Alexandre
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
> >
> >
> >
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.






Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Eliot Miranda-2
In reply to this post by David T. Lewis


On Mon, Jan 3, 2011 at 12:46 PM, David T. Lewis <[hidden email]> wrote:
On Mon, Jan 03, 2011 at 09:14:47PM +0100, Philippe Marschall wrote:
> On 03.01.2011 16:42, David T. Lewis wrote:
> > On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote:
> >> On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
> >>> Hi!
> >>>
> >>> Sorry for the late answer. The student is now in my office and there is indeed a problem.
> >>> UUIDPlugin is not present on his harddisk. Maybe built in the VM.
> >>>
> >>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
> >>
> >> Has been known for two years, shouldn't happen, nobody cares.
> >>
> >
> > Huh ?!?!? What do you mean "nobody cares"?
>
> Nodby cares enough to get to the bottom of it and fix it once and for
> all. And yes, that includes me. It's just an observation. So if this is
> really critical for somebody then he'll have to fix it himself.
> Reporting the same bug again won't make a difference. That's just how
> open source is.
>
> Cheers
> Philippe
>

Yep :)

But I do want to make it clear that it seems the bug is not in
the plugin, it is in the libuuid implementations. We've all been
trying to find workarounds, but unfortunately not with much
success. For a while we could work around it by compiling the
plugin internally (which somehow prevents the bug from being
exposed), but now we have some 64-bit Linux distros that accidentally
left the 32-bit libuuid out of the distro, which prevents the VM
from running if the plugin was compiled internally. I'm sure it
has been fixed in up to date distros, but now we have one set of
Linux users with buggy libuuid libraries, and another set of Linux
users with missing 32-bit libuuid libraries, so somebody is going
to get screwed either way now :-/

I'm sure there must be some way to fix this that we're all missing,
so if anyone wants to look at it with a fresh set of eyes that
would be great.

If it is possible in the startup script to check whether the libuuid installation is correct then the startup script could print an error message plus information on how to correct the installation.  IMO, this would be better than either crashing after startup or hacking the image to avoid the primitive because of a platform error.  The issue then is how to check.  One straight-forward way would be for the start-up script to invoke a small C program that invoked libuuid in exactly the same way as the UUIDPlugin, and if this fails then the startup script can warn.  The issue remains how to correct the installation once the error has been detected.

Eliot


Dave



Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Mariano Martinez Peck


On Mon, Jan 3, 2011 at 10:36 PM, Eliot Miranda <[hidden email]> wrote:


On Mon, Jan 3, 2011 at 12:46 PM, David T. Lewis <[hidden email]> wrote:
On Mon, Jan 03, 2011 at 09:14:47PM +0100, Philippe Marschall wrote:
> On 03.01.2011 16:42, David T. Lewis wrote:
> > On Mon, Jan 03, 2011 at 03:57:07PM +0100, Philippe Marschall wrote:
> >> On 01/03/2011 03:25 PM, Alexandre Bergel wrote:
> >>> Hi!
> >>>
> >>> Sorry for the late answer. The student is now in my office and there is indeed a problem.
> >>> UUIDPlugin is not present on his harddisk. Maybe built in the VM.
> >>>
> >>> I found the class UUID and remove the call to the primitive. It works. Strange problem. Shall I report it in codegoogle?
> >>
> >> Has been known for two years, shouldn't happen, nobody cares.
> >>
> >
> > Huh ?!?!? What do you mean "nobody cares"?
>
> Nodby cares enough to get to the bottom of it and fix it once and for
> all. And yes, that includes me. It's just an observation. So if this is
> really critical for somebody then he'll have to fix it himself.
> Reporting the same bug again won't make a difference. That's just how
> open source is.
>
> Cheers
> Philippe
>

Yep :)

But I do want to make it clear that it seems the bug is not in
the plugin, it is in the libuuid implementations. We've all been
trying to find workarounds, but unfortunately not with much
success. For a while we could work around it by compiling the
plugin internally (which somehow prevents the bug from being
exposed), but now we have some 64-bit Linux distros that accidentally
left the 32-bit libuuid out of the distro, which prevents the VM
from running if the plugin was compiled internally. I'm sure it
has been fixed in up to date distros, but now we have one set of
Linux users with buggy libuuid libraries, and another set of Linux
users with missing 32-bit libuuid libraries, so somebody is going
to get screwed either way now :-/

I'm sure there must be some way to fix this that we're all missing,
so if anyone wants to look at it with a fresh set of eyes that
would be great.

If it is possible in the startup script to check whether the libuuid installation is correct then the startup script could print an error message plus information on how to correct the installation.  IMO, this would be better than either crashing after startup or hacking the image to avoid the primitive because of a platform error.  The issue then is how to check.  One straight-forward way would be for the start-up script to invoke a small C program that invoked libuuid in exactly the same way as the UUIDPlugin, and if this fails then the startup script can warn.  The issue remains how to correct the installation once the error has been detected.

Hi Eliot. I agree that your suggestion is better, but for that reason, we have been dealing with this for more than 2 years. So:

- hacking the image is not the best solution but it can be integrated in pharo in less than 5 minutes and working out of the box. Ok, we do not use the plugin if it is UNIX directly...even if that distro may be working

- hacking the image is better than crashing the system while doing something as basic as a simple commit. VM should crash as less as possible.

Providing such script (the one you say), integrate them in the pharo one clicks, testing it in several OS, and of course, how to CODE that piece of C/Shell or whatever you use, and how to know if the installation of libuuid is broken.
I think that pretending this solution is why this problem is present since 2 years already.

Hacking the image (or fixing a basic crash) can be done in 5 minutes and it is muuch better than a crash. If you, or someone, come after with a better solution, there is no problem. Such changes can be reverted in another 5 minutes. We are flexible ;)

Just my opinion

Mariano
 

Eliot


Dave




Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Stéphane Ducasse
In reply to this post by David T. Lewis

> Yep :)
>
> But I do want to make it clear that it seems the bug is not in
> the plugin, it is in the libuuid implementations. We've all been
> trying to find workarounds, but unfortunately not with much
> success. For a while we could work around it by compiling the
> plugin internally (which somehow prevents the bug from being
> exposed), but now we have some 64-bit Linux distros that accidentally
> left the 32-bit libuuid out of the distro, which prevents the VM
> from running if the plugin was compiled internally. I'm sure it
> has been fixed in up to date distros, but now we have one set of
> Linux users with buggy libuuid libraries, and another set of Linux
> users with missing 32-bit libuuid libraries, so somebody is going
> to get screwed either way now :-/

;(
May be should put a large readme file somewhere explaining the situation.

>
> I'm sure there must be some way to fix this that we're all missing,
> so if anyone wants to look at it with a fresh set of eyes that
> would be great.
>
> Dave
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Crash on saving with Monticello

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
>
> If it is possible in the startup script to check whether the libuuid installation is correct then the startup script could print an error message plus information on how to correct the installation.  IMO, this would be better than either crashing after startup or hacking the image to avoid the primitive because of a platform error.  The issue then is how to check.  One straight-forward way would be for the start-up script to invoke a small C program that invoked libuuid in exactly the same way as the UUIDPlugin, and if this fails then the startup script can warn.  The issue remains how to correct the installation once the error has been detected.
>

yes this sounds a good way to deal with it.