UUID and Cog?
Locked
12
12
 
|
Hi
Does anybody know whether UUIDs are supposed to work on Cog on Linux? I got the latest prebuilt Cog from [1] and UUID new crashes my VM with a seg fault on a Monticello commit. I believe it was working before I updated some Linux packages. [1] http://www.mirandabanda.org/files/Cog/VM/VM.r2316/ Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Same problem, discussed a few days ago: http://forum.world.st/ANN-Pharo-1-1-1-OneClickCogVm-tp2713612p2720604.html
Laurent
On Tue, Oct 5, 2010 at 11:28 AM, Philippe Marschall <[hidden email]> wrote: Hi _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
http://bugs.squeak.org/view.php?id=7371
http://bugs.squeak.org/view.php?id=7358 http://code.google.com/p/pharo/issues/detail?id=855 I don't think it is really resolved, but the workaround (remove the UUID plugin) might still work Nicolas 2010/10/5 laurent laffont <[hidden email]>: > Same problem, discussed a few days > ago: http://forum.world.st/ANN-Pharo-1-1-1-OneClickCogVm-tp2713612p2720604.html > Laurent > > On Tue, Oct 5, 2010 at 11:28 AM, Philippe Marschall <[hidden email]> wrote: >> >> Hi >> >> Does anybody know whether UUIDs are supposed to work on Cog on Linux? I >> got the latest prebuilt Cog from [1] and UUID new crashes my VM with a >> seg fault on a Monticello commit. I believe it was working before I >> updated some Linux packages. >> >> [1] http://www.mirandabanda.org/files/Cog/VM/VM.r2316/ >> >> Cheers >> Philippe >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Philippe Marschall-2-3
On Tue, 5 Oct 2010, Philippe Marschall wrote:
> Hi > > Does anybody know whether UUIDs are supposed to work on Cog on Linux? I > got the latest prebuilt Cog from [1] and UUID new crashes my VM with a > seg fault on a Monticello commit. I believe it was working before I > updated some Linux packages. Just rebuild the VM on your Linux, that should work. Levente > > [1] http://www.mirandabanda.org/files/Cog/VM/VM.r2316/ > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
If anyone has any specific information as to the root cause of the libuuid
bug, I'd appreciate if you can update the bug report here: http://bugs.squeak.org/view.php?id=7358 I had previously tried to summarize as follows: > The bug exists in some versions of libuuid on some Linux distributions. > The workaround is to compile the plugin internal. The latest versions > of Unix VM have the plugin compiled internally, although some users may > still experience problems if they have a leftover external plugin from > a prior installation. But it's not clear if this is accurate given the recent reports here. In particular, if a precompiled Cog VM with the UUID plugin compiled internally leads to a crash, then the above is not a sufficient workaround (at least not on Cog). If we are seeing crashes on Cog with an internal UUID plugin, but not on the traditional VM with an internal UUID plugin, then I think I smell a pthread related issue. Thanks, Dave On Tue, Oct 05, 2010 at 02:13:46PM +0200, Levente Uzonyi wrote: > On Tue, 5 Oct 2010, Philippe Marschall wrote: > > >Hi > > > >Does anybody know whether UUIDs are supposed to work on Cog on Linux? I > >got the latest prebuilt Cog from [1] and UUID new crashes my VM with a > >seg fault on a Monticello commit. I believe it was working before I > >updated some Linux packages. > > Just rebuild the VM on your Linux, that should work. > > > Levente > > > > >[1] http://www.mirandabanda.org/files/Cog/VM/VM.r2316/ > > > >Cheers > >Philippe > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 05.10.2010 16:41, David T. Lewis wrote:
> If anyone has any specific information as to the root cause of the libuuid > bug, I'd appreciate if you can update the bug report here: > > http://bugs.squeak.org/view.php?id=7358 > > I had previously tried to summarize as follows: > >> The bug exists in some versions of libuuid on some Linux distributions. >> The workaround is to compile the plugin internal. The latest versions >> of Unix VM have the plugin compiled internally, although some users may >> still experience problems if they have a leftover external plugin from >> a prior installation. > > But it's not clear if this is accurate given the recent reports here. > In particular, if a precompiled Cog VM with the UUID plugin compiled > internally leads to a crash, then the above is not a sufficient > workaround (at least not on Cog). > > If we are seeing crashes on Cog with an internal UUID plugin, but > not on the traditional VM with an internal UUID plugin, then I think > I smell a pthread related issue. How can I find out whether the plugin is compiled internally or not? What I see in the console is the following: Segmentation fault Smalltalk stack dump: 0xff79f344 M UUID>initialize -1045926312: a(n) UUID 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class 0xff79f380 I UUID class>new -1246728604: a(n) UUID class ... Most recent primitives ... withArgs:executeMethod: basicNew: primMakeUUID Is there a way to provide more information? Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Oct 5, 2010 at 5:22 PM, Philippe Marschall <[hidden email]> wrote:
SmalltalkImage current listBuiltinModules Laurent What I see in the console is the following: _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Philippe Marschall-2-3
On Tue, 5 Oct 2010, Philippe Marschall wrote:
> On 05.10.2010 16:41, David T. Lewis wrote: >> If anyone has any specific information as to the root cause of the libuuid >> bug, I'd appreciate if you can update the bug report here: >> >> http://bugs.squeak.org/view.php?id=7358 >> >> I had previously tried to summarize as follows: >> >>> The bug exists in some versions of libuuid on some Linux distributions. >>> The workaround is to compile the plugin internal. The latest versions >>> of Unix VM have the plugin compiled internally, although some users may >>> still experience problems if they have a leftover external plugin from >>> a prior installation. >> >> But it's not clear if this is accurate given the recent reports here. >> In particular, if a precompiled Cog VM with the UUID plugin compiled >> internally leads to a crash, then the above is not a sufficient >> workaround (at least not on Cog). >> >> If we are seeing crashes on Cog with an internal UUID plugin, but >> not on the traditional VM with an internal UUID plugin, then I think >> I smell a pthread related issue. > > How can I find out whether the plugin is compiled internally or not? The crash report lists the loaded plugins. If the plugin name ends with (i), then it's internal, if it ends with (e), then it's external. If you're using Eliot's build, then it's external. If you just want a working VM and the quality of UUIDs doesn't matter, then you can safely delete the UUIDPlugin from the lib/squeak/3.9-7/ directory. > > What I see in the console is the following: > > Segmentation fault > > > > Smalltalk stack dump: > 0xff79f344 M UUID>initialize -1045926312: a(n) UUID > 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class > 0xff79f380 I UUID class>new -1246728604: a(n) UUID class > > ... > > Most recent primitives > ... > withArgs:executeMethod: > basicNew: > primMakeUUID > > Is there a way to provide more information? The stack dump looks the same as what other people have. The version of your linux might be helpful, so others can reproduce the issue if you don't want to debug it yourself. Levente > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On Tue, Oct 5, 2010 at 5:13 AM, Levente Uzonyi <[hidden email]> wrote:
In fact, just rebuild the plugin. Here's how. Once you've checked out http://www.squeakvm.org/svn/squeak/branches/Cog, read and obeyed unixbuild/HowToBuild through the configure step cd to
unixbuild/bld/UUIDPlugin and say "make". Then take the plugin from unixbuild/bld/UUIDPlugin/.libs/UUIDPlugin HTH Eliot
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On 05.10.2010 18:23, Levente Uzonyi wrote:
> On Tue, 5 Oct 2010, Philippe Marschall wrote: > >> On 05.10.2010 16:41, David T. Lewis wrote: >>> If anyone has any specific information as to the root cause of the >>> libuuid >>> bug, I'd appreciate if you can update the bug report here: >>> >>> http://bugs.squeak.org/view.php?id=7358 >>> >>> I had previously tried to summarize as follows: >>> >>>> The bug exists in some versions of libuuid on some Linux distributions. >>>> The workaround is to compile the plugin internal. The latest versions >>>> of Unix VM have the plugin compiled internally, although some users may >>>> still experience problems if they have a leftover external plugin from >>>> a prior installation. >>> >>> But it's not clear if this is accurate given the recent reports here. >>> In particular, if a precompiled Cog VM with the UUID plugin compiled >>> internally leads to a crash, then the above is not a sufficient >>> workaround (at least not on Cog). >>> >>> If we are seeing crashes on Cog with an internal UUID plugin, but >>> not on the traditional VM with an internal UUID plugin, then I think >>> I smell a pthread related issue. >> >> How can I find out whether the plugin is compiled internally or not? > > The crash report lists the loaded plugins. If the plugin name ends with > (i), then it's internal, if it ends with (e), then it's external. If > you're using Eliot's build, then it's external. Yeah, that's what I'm using, it's external. > If you just want a working VM and the quality of UUIDs doesn't matter, > then you can safely delete the UUIDPlugin from the lib/squeak/3.9-7/ > directory. Uhm, I'm making Monticello commits and good UUIDs would help. >> >> What I see in the console is the following: >> >> Segmentation fault >> >> >> >> Smalltalk stack dump: >> 0xff79f344 M UUID>initialize -1045926312: a(n) UUID >> 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class >> 0xff79f380 I UUID class>new -1246728604: a(n) UUID class >> >> ... >> >> Most recent primitives >> ... >> withArgs:executeMethod: >> basicNew: >> primMakeUUID >> >> Is there a way to provide more information? > > The stack dump looks the same as what other people have. The version of > your linux might be helpful, so others can reproduce the issue if you > don't want to debug it yourself. Gentoo 64bit: 2.6.35-gentoo-r8 util-linux (where libuuid afaik comes from): 2.18-r1 Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
...and if you want to try and make the UUIDPlugin internal you need to edit unixbuild/bld/plugins.int & unixbuild/bld/plugins.ext to move it from external to internal, then (if you've already configured) make reallyclean and repeat the configure step before making.
On Tue, Oct 5, 2010 at 10:18 AM, Eliot Miranda <[hidden email]> wrote:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
On Tue, Oct 05, 2010 at 10:18:28AM -0700, Eliot Miranda wrote:
> On Tue, Oct 5, 2010 at 5:13 AM, Levente Uzonyi <[hidden email]> wrote: > > > On Tue, 5 Oct 2010, Philippe Marschall wrote: > > > > Hi > >> > >> Does anybody know whether UUIDs are supposed to work on Cog on Linux? I > >> got the latest prebuilt Cog from [1] and UUID new crashes my VM with a > >> seg fault on a Monticello commit. I believe it was working before I > >> updated some Linux packages. > >> > > > > Just rebuild the VM on your Linux, that should work. > > > > In fact, just rebuild the plugin. Here's how. Once you've checked out > http://www.squeakvm.org/svn/squeak/branches/Cog, read and obeyed > unixbuild/HowToBuild through the configure step cd to > unixbuild/bld/UUIDPlugin > and say "make". Then take the plugin from > unixbuild/bld/UUIDPlugin/.libs/UUIDPlugin Eliot, Would it be possible for you to build a VM with UUIDPlugin compiled internally, building it on the same machine that you normally use, and give it to Philippe to test? If it works, then the information on http://bugs.squeak.org/view.php?id=7358 is probably valid for Cog as well as for the regular VM. If it does not work, then there is more to the problem and I'll reopen the issue on Mantis. As far as I know, there have been no reports of libuuid failures on the Unix VMs since Ian changed to using an internal UUIDPlugin, so this is an easy fix if it works for Cog also. Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Eliot Miranda-2
>
> Eliot, > > Would it be possible for you to build a VM with UUIDPlugin compiled > internally, building it on the same machine that you normally use, > and give it to Philippe to test? If it works, then the information > on http://bugs.squeak.org/view.php?id=7358 is probably valid for > Cog as well as for the regular VM. If it does not work, then there > is more to the problem and I'll reopen the issue on Mantis. > > As far as I know, there have been no reports of libuuid failures on > the Unix VMs since Ian changed to using an internal UUIDPlugin, so > this is an easy fix if it works for Cog also. > > Dave Hi dave At esug I started to pair program with a student and on her machine the lastest pharo oneclick (but I do not know which one it was) showed the same problem. I remember she was on ubuntu. Now I was too busy and I should have pay attention to collect all the information. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Philippe Marschall-2-3
On Tue, 5 Oct 2010, Philippe Marschall wrote:
> On 05.10.2010 18:23, Levente Uzonyi wrote: >> On Tue, 5 Oct 2010, Philippe Marschall wrote: >> >>> On 05.10.2010 16:41, David T. Lewis wrote: >>>> If anyone has any specific information as to the root cause of the >>>> libuuid >>>> bug, I'd appreciate if you can update the bug report here: >>>> >>>> http://bugs.squeak.org/view.php?id=7358 >>>> >>>> I had previously tried to summarize as follows: >>>> >>>>> The bug exists in some versions of libuuid on some Linux distributions. >>>>> The workaround is to compile the plugin internal. The latest versions >>>>> of Unix VM have the plugin compiled internally, although some users may >>>>> still experience problems if they have a leftover external plugin from >>>>> a prior installation. >>>> >>>> But it's not clear if this is accurate given the recent reports here. >>>> In particular, if a precompiled Cog VM with the UUID plugin compiled >>>> internally leads to a crash, then the above is not a sufficient >>>> workaround (at least not on Cog). >>>> >>>> If we are seeing crashes on Cog with an internal UUID plugin, but >>>> not on the traditional VM with an internal UUID plugin, then I think >>>> I smell a pthread related issue. >>> >>> How can I find out whether the plugin is compiled internally or not? >> >> The crash report lists the loaded plugins. If the plugin name ends with >> (i), then it's internal, if it ends with (e), then it's external. If >> you're using Eliot's build, then it's external. > > Yeah, that's what I'm using, it's external. > >> If you just want a working VM and the quality of UUIDs doesn't matter, >> then you can safely delete the UUIDPlugin from the lib/squeak/3.9-7/ >> directory. > > Uhm, I'm making Monticello commits and good UUIDs would help. > I think the UUIDGenerator in the image produces UUIDs which are good enough for MC. >>> >>> What I see in the console is the following: >>> >>> Segmentation fault >>> >>> >>> >>> Smalltalk stack dump: >>> 0xff79f344 M UUID>initialize -1045926312: a(n) UUID >>> 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class >>> 0xff79f380 I UUID class>new -1246728604: a(n) UUID class >>> >>> ... >>> >>> Most recent primitives >>> ... >>> withArgs:executeMethod: >>> basicNew: >>> primMakeUUID >>> >>> Is there a way to provide more information? >> >> The stack dump looks the same as what other people have. The version of >> your linux might be helpful, so others can reproduce the issue if you >> don't want to debug it yourself. > > Gentoo 64bit: 2.6.35-gentoo-r8 > util-linux (where libuuid afaik comes from): 2.18-r1 Do you have a 32-bit version of libuuid installed? If not, it won't work. What does "ldd UUIDPlugin" print? Levente > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by David T. Lewis
On Tue, 5 Oct 2010, David T. Lewis wrote:
> On Tue, Oct 05, 2010 at 10:18:28AM -0700, Eliot Miranda wrote: >> On Tue, Oct 5, 2010 at 5:13 AM, Levente Uzonyi <[hidden email]> wrote: >> >>> On Tue, 5 Oct 2010, Philippe Marschall wrote: >>> >>> Hi >>>> >>>> Does anybody know whether UUIDs are supposed to work on Cog on Linux? I >>>> got the latest prebuilt Cog from [1] and UUID new crashes my VM with a >>>> seg fault on a Monticello commit. I believe it was working before I >>>> updated some Linux packages. >>>> >>> >>> Just rebuild the VM on your Linux, that should work. >>> >> >> In fact, just rebuild the plugin. Here's how. Once you've checked out >> http://www.squeakvm.org/svn/squeak/branches/Cog, read and obeyed >> unixbuild/HowToBuild through the configure step cd to >> unixbuild/bld/UUIDPlugin >> and say "make". Then take the plugin from >> unixbuild/bld/UUIDPlugin/.libs/UUIDPlugin > > Eliot, > > Would it be possible for you to build a VM with UUIDPlugin compiled > internally, building it on the same machine that you normally use, > and give it to Philippe to test? If it works, then the information > on http://bugs.squeak.org/view.php?id=7358 is probably valid for > Cog as well as for the regular VM. If it does not work, then there > is more to the problem and I'll reopen the issue on Mantis. > > As far as I know, there have been no reports of libuuid failures on > the Unix VMs since Ian changed to using an internal UUIDPlugin, so > this is an easy fix if it works for Cog also. If libuuid is not available, the internally built UUIDPlugin crashes the VM. Levente > > Dave > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Does the crash happen if the plugin is built on a machine without the library, or if it is run on a machine without it?
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]] Sent: Tuesday, October 05, 2010 10:37 PM To: [hidden email] Subject: Re: [Pharo-project] UUID and Cog? On Tue, 5 Oct 2010, David T. Lewis wrote: > On Tue, Oct 05, 2010 at 10:18:28AM -0700, Eliot Miranda wrote: >> On Tue, Oct 5, 2010 at 5:13 AM, Levente Uzonyi <[hidden email]> wrote: >> >>> On Tue, 5 Oct 2010, Philippe Marschall wrote: >>> >>> Hi >>>> >>>> Does anybody know whether UUIDs are supposed to work on Cog on Linux? I >>>> got the latest prebuilt Cog from [1] and UUID new crashes my VM with a >>>> seg fault on a Monticello commit. I believe it was working before I >>>> updated some Linux packages. >>>> >>> >>> Just rebuild the VM on your Linux, that should work. >>> >> >> In fact, just rebuild the plugin. Here's how. Once you've checked out >> http://www.squeakvm.org/svn/squeak/branches/Cog, read and obeyed >> unixbuild/HowToBuild through the configure step cd to >> unixbuild/bld/UUIDPlugin >> and say "make". Then take the plugin from >> unixbuild/bld/UUIDPlugin/.libs/UUIDPlugin > > Eliot, > > Would it be possible for you to build a VM with UUIDPlugin compiled > internally, building it on the same machine that you normally use, > and give it to Philippe to test? If it works, then the information > on http://bugs.squeak.org/view.php?id=7358 is probably valid for > Cog as well as for the regular VM. If it does not work, then there > is more to the problem and I'll reopen the issue on Mantis. > > As far as I know, there have been no reports of libuuid failures on > the Unix VMs since Ian changed to using an internal UUIDPlugin, so > this is an easy fix if it works for Cog also. If libuuid is not available, the internally built UUIDPlugin crashes the VM. Levente > > Dave > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, 5 Oct 2010, Schwab,Wilhelm K wrote:
> Does the crash happen if the plugin is built on a machine without the library, or if it is run on a machine without it? The latter, but I wonder how can you build the plugin without the library. Levente > > > > ________________________________________ > From: [hidden email] [[hidden email]] On Behalf Of Levente Uzonyi [[hidden email]] > Sent: Tuesday, October 05, 2010 10:37 PM > To: [hidden email] > Subject: Re: [Pharo-project] UUID and Cog? > > On Tue, 5 Oct 2010, David T. Lewis wrote: > >> On Tue, Oct 05, 2010 at 10:18:28AM -0700, Eliot Miranda wrote: >>> On Tue, Oct 5, 2010 at 5:13 AM, Levente Uzonyi <[hidden email]> wrote: >>> >>>> On Tue, 5 Oct 2010, Philippe Marschall wrote: >>>> >>>> Hi >>>>> >>>>> Does anybody know whether UUIDs are supposed to work on Cog on Linux? I >>>>> got the latest prebuilt Cog from [1] and UUID new crashes my VM with a >>>>> seg fault on a Monticello commit. I believe it was working before I >>>>> updated some Linux packages. >>>>> >>>> >>>> Just rebuild the VM on your Linux, that should work. >>>> >>> >>> In fact, just rebuild the plugin. Here's how. Once you've checked out >>> http://www.squeakvm.org/svn/squeak/branches/Cog, read and obeyed >>> unixbuild/HowToBuild through the configure step cd to >>> unixbuild/bld/UUIDPlugin >>> and say "make". Then take the plugin from >>> unixbuild/bld/UUIDPlugin/.libs/UUIDPlugin >> >> Eliot, >> >> Would it be possible for you to build a VM with UUIDPlugin compiled >> internally, building it on the same machine that you normally use, >> and give it to Philippe to test? If it works, then the information >> on http://bugs.squeak.org/view.php?id=7358 is probably valid for >> Cog as well as for the regular VM. If it does not work, then there >> is more to the problem and I'll reopen the issue on Mantis. >> >> As far as I know, there have been no reports of libuuid failures on >> the Unix VMs since Ian changed to using an internal UUIDPlugin, so >> this is an easy fix if it works for Cog also. > > If libuuid is not available, the internally built UUIDPlugin crashes the > VM. > > > Levente > >> >> Dave >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On Tue, Oct 5, 2010 at 7:37 PM, Levente Uzonyi <[hidden email]> wrote:
And if libuuid is unavailable the external plugin does not load and hence does not crash the VM, but silently fails to use the Squeak UUID code.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
On 06.10.2010 04:35, Levente Uzonyi wrote:
> On Tue, 5 Oct 2010, Philippe Marschall wrote: > >> On 05.10.2010 18:23, Levente Uzonyi wrote: >>> On Tue, 5 Oct 2010, Philippe Marschall wrote: >>> >>>> On 05.10.2010 16:41, David T. Lewis wrote: >>>>> If anyone has any specific information as to the root cause of the >>>>> libuuid >>>>> bug, I'd appreciate if you can update the bug report here: >>>>> >>>>> http://bugs.squeak.org/view.php?id=7358 >>>>> >>>>> I had previously tried to summarize as follows: >>>>> >>>>>> The bug exists in some versions of libuuid on some Linux >>>>>> distributions. >>>>>> The workaround is to compile the plugin internal. The latest versions >>>>>> of Unix VM have the plugin compiled internally, although some >>>>>> users may >>>>>> still experience problems if they have a leftover external plugin >>>>>> from >>>>>> a prior installation. >>>>> >>>>> But it's not clear if this is accurate given the recent reports here. >>>>> In particular, if a precompiled Cog VM with the UUID plugin compiled >>>>> internally leads to a crash, then the above is not a sufficient >>>>> workaround (at least not on Cog). >>>>> >>>>> If we are seeing crashes on Cog with an internal UUID plugin, but >>>>> not on the traditional VM with an internal UUID plugin, then I think >>>>> I smell a pthread related issue. >>>> >>>> How can I find out whether the plugin is compiled internally or not? >>> >>> The crash report lists the loaded plugins. If the plugin name ends with >>> (i), then it's internal, if it ends with (e), then it's external. If >>> you're using Eliot's build, then it's external. >> >> Yeah, that's what I'm using, it's external. >> >>> If you just want a working VM and the quality of UUIDs doesn't matter, >>> then you can safely delete the UUIDPlugin from the lib/squeak/3.9-7/ >>> directory. >> >> Uhm, I'm making Monticello commits and good UUIDs would help. >> > > I think the UUIDGenerator in the image produces UUIDs which are good > enough for MC. > >>>> >>>> What I see in the console is the following: >>>> >>>> Segmentation fault >>>> >>>> >>>> >>>> Smalltalk stack dump: >>>> 0xff79f344 M UUID>initialize -1045926312: a(n) UUID >>>> 0xff79f35c M UUID class(Behavior)>new: -1246728604: a(n) UUID class >>>> 0xff79f380 I UUID class>new -1246728604: a(n) UUID class >>>> >>>> ... >>>> >>>> Most recent primitives >>>> ... >>>> withArgs:executeMethod: >>>> basicNew: >>>> primMakeUUID >>>> >>>> Is there a way to provide more information? >>> >>> The stack dump looks the same as what other people have. The version of >>> your linux might be helpful, so others can reproduce the issue if you >>> don't want to debug it yourself. >> >> Gentoo 64bit: 2.6.35-gentoo-r8 >> util-linux (where libuuid afaik comes from): 2.18-r1 > > Do you have a 32-bit version of libuuid installed? If not, it won't work. I believe so. > What does "ldd UUIDPlugin" print? $dd UUIDPlugin linux-gate.so.1 => (0xffffe000) libuuid.so.1 => /lib32/libuuid.so.1 (0xf771f000) libc.so.6 => /lib32/libc.so.6 (0xf75c4000) /lib/ld-linux.so.2 (0xf7762000) Cheers Philippe _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Levente Uzonyi-2
Moving to vm-dev list for follow up related to the UUIDPlugin.
On Wed, Oct 06, 2010 at 04:37:00AM +0200, Levente Uzonyi wrote: > On Tue, 5 Oct 2010, David T. Lewis wrote: <unrelated discussion of Cog configurations snipped> > >As far as I know, there have been no reports of libuuid failures on > >the Unix VMs since Ian changed to using an internal UUIDPlugin, so > >this is an easy fix if it works for Cog also. > > If libuuid is not available, the internally built UUIDPlugin crashes the > VM. > > Levente Levente, thanks for identifying this. I was able to reproduce this on my system by removing the libuuid libraries, after which a VM with internal UUIDPlugin refuses to load: /usr/local/lib/squeak/4.3.4-2316/squeakvm: error while loading shared libraries: libuuid.so.1: cannot open shared object file: No such file or directory I reopened the issue on Mantis http://bugs.squeak.org/view.php?id=7358 with the following explanation: > Changing status from resolved back to acknowledged. Levente Uzonyi > reports that the plugin, if built internally, will crash the VM if > the target system does not have libuuid installed. > > http://lists.gforge.inria.fr/pipermail/pharo-project/2010-October/033760.html [^] > > I reproduced this by removing the libuuid libraries from my Linux system. > The result is that the VM fails to load due to the missing library. It > never reaches main(), so this is not something that can be addressed in > the code. Presumably a static linked VM would work, but this would > probably lead to problems elsewhere. > > Summary: Building UUIDPlugin internally is a workaround for the libuuid > bug that is present on some systems, but it results in an unusable VM for > people who do not have the uuid library installed with their OS. Levente, can you say anything about what OS platforms would not have libuuid installed? I am guessing that it is a scenario involving a 64-bit OS for which some of the 32-bit runtime libraries were not installed, but if you can clarify this it would be helpful. Thanks! Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |