Re: [Pharo-project] new Cog VMs
I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to run it from the top-level pharo directory as: coglinux/squeak Contents/Resources/pharo.image crashes immediately (with or without the -vm-display-X11 option). This is on latest Fedora 14. The old VM seems to have no problem when I try to run it the same way: Contents/Linux/squeakvm Contents/Resources/pharo.image seems to start just fine. I can copy the stack dump from the crash, but since most seem to be running fine, I suspect I'm just not doing it right. What am I missing ? Thanks, Martin "Eliot Miranda"<eliot.miranda@gmail.com> wrote:
there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2339/<http://www.mirandabanda.org/files/Cog/VM/VM.r2339/> & VM.r2340/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2340/> respectively. These contain fixes for rounding bug causing underestimate of openPICSize and resultant hard crashes, seen e.g. by trying to recover lost changes in a Pharo 1.2 image installed on c:\pharo. If you're trying to reproduce Cog crashes please upgrade to one of tthese two VMs.
Hi Martin, crashing immediately on startup could be to do with the UUIDPlugin and libuuid. Try removing coglinux/lib/squeak/3.9-7/UUIDPlugin and see if it makes a difference. If it does I believe the fix is to ensure that there's a 32-bit libuuid.so.1 installed. e.g. [eliot@mcqfes bld]$ ldd coglinux/lib/squeak/3.9-7/UUIDPlugin linux-gate.so.1 => (0x00e2e000) libuuid.so.1 => /lib/libuuid.so.1 (0x0067e000) libc.so.6 => /lib/libc.so.6 (0x008d6000) /lib/ld-linux.so.2 (0x0045a000) [eliot@mcqfes bld]$ file /lib/libuuid.so.1 /lib/libuuid.so.1: symbolic link to `libuuid.so.1.2' [eliot@mcqfes bld]$ file /lib/libuuid.so.1.2 /lib/libuuid.so.1.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped Search the Squeak, vm-dev and Pharo archives for info on how to install a 32-bit version. I think it was mentioned within the last month. If your problem is nothing to do with libuuid then I need info like exact OS version, what directories you've installed things in and a gdb backtrace for the crash. HTH Eliot On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic@gmail.com> wrote:
I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to run it from the top-level pharo directory as:
coglinux/squeak Contents/Resources/pharo.image
crashes immediately (with or without the -vm-display-X11 option). This is on latest Fedora 14. The old VM seems to have no problem when I try to run it the same way:
Contents/Linux/squeakvm Contents/Resources/pharo.image
seems to start just fine. I can copy the stack dump from the crash, but since most seem to be running fine, I suspect I'm just not doing it right. What am I missing ?
Thanks,
Martin
"Eliot Miranda"<eliot.miranda@gmail.com> wrote:
there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2339/<http://www.mirandabanda.org/files/Cog/VM/VM.r2339/> & VM.r2340/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2340/> respectively. These contain fixes for rounding bug causing underestimate of openPICSize and resultant hard crashes, seen e.g. by trying to recover lost changes in a Pharo 1.2 image installed on c:\pharo. If you're trying to reproduce Cog crashes please upgrade to one of tthese two VMs.
Hi Martin, Hi All, so find new VMs in VM.r2341/<http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee). I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet). So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2). I'm not proud of this "fix". I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground. Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again. best Eliot On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic@gmail.com> wrote:
I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to run it from the top-level pharo directory as:
coglinux/squeak Contents/Resources/pharo.image
crashes immediately (with or without the -vm-display-X11 option). This is on latest Fedora 14. The old VM seems to have no problem when I try to run it the same way:
Contents/Linux/squeakvm Contents/Resources/pharo.image
seems to start just fine. I can copy the stack dump from the crash, but since most seem to be running fine, I suspect I'm just not doing it right. What am I missing ?
Thanks,
Martin
"Eliot Miranda"<eliot.miranda@gmail.com> wrote:
there are new versions of both the SimpleStackBasedCogit and the StackToRegisterMappingCogit Cog VMs in VM.r2339/<http://www.mirandabanda.org/files/Cog/VM/VM.r2339/> & VM.r2340/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2340/> respectively. These contain fixes for rounding bug causing underestimate of openPICSize and resultant hard crashes, seen e.g. by trying to recover lost changes in a Pharo 1.2 image installed on c:\pharo. If you're trying to reproduce Cog crashes please upgrade to one of tthese two VMs.
On 3 January 2011 00:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Martin, Hi All,    so find new VMs in VM.r2341/.  The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee).  I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet). So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this "fix".  I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground.  Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again.
Eliot, if you remember, i also had crash issues on linux, and pinned down it to removing optimization from <something>heartbeat.c while keeping gcc3x-cointerp.c to use same optimization flags as for rest of files. I will start coding cmake config for Cog during next week and will be able to check my previous observations again.
best Eliot On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic@gmail.com> wrote:
-- Best regards, Igor Stasenko AKA sig.
Hi Igor, Hi All, On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 January 2011 00:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Martin, Hi All, so find new VMs in VM.r2341/. The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee). I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet). So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2). I'm not proud of this "fix". I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground. Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again.
Eliot, if you remember, i also had crash issues on linux, and pinned down it to removing optimization from <something>heartbeat.c while keeping gcc3x-cointerp.c to use same optimization flags as for rest of files.
Indeed, quite right. I happened to add a flag to turn off the heartbeat so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away. This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does. I'll try and pass it by someone who's an expert in this area. Anyway, now find a new linux VM in VM.r2346/<http://www.mirandabanda.org/files/Cog/VM/VM.r2346/> that seems fine with the interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2. Running this VM on CentOS 5.3 under Parallels I get 2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 unexpected passes for the full test suite in Squeak4.2-10856-beta.image. So have at it. best Eliot
I will start coding cmake config for Cog during next week and will be able to check my previous observations again.
best Eliot On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic@gmail.com> wrote:
-- Best regards, Igor Stasenko AKA sig.
Indeed, quite right. I happened to add a flag to turn off the heartbeat so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away. This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does. I'll try and pass it by someone who's an expert in this area.
Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc... Andres.
On Mon, Jan 10, 2011 at 11:31 PM, Andres Valloud < avalloud@smalltalk.comcastbiz.net> wrote:
Indeed, quite right. I happened to add a flag to turn off the heartbeat
so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away. This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does. I'll try and pass it by someone who's an expert in this area.
Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc...
Good point. The signal handler essentially calls gettimeofday (not on the approved list but time is) and sets a couple of variables (current 64-bit microsecond time, stackLimit). But it does not preserve errno. I don't want to avoid calling gettimeofday and can see no harm in it; it's equivalent internally to time providing it doesn't use its TIMEZONE arg (which it doesn't). But the signal handler /doesn't/ preserve errno and doing so is a very good idea and easy to do. Thanks.
Andres.
Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc...
Good point. The signal handler essentially calls gettimeofday (not on the approved list but time is) and sets a couple of variables (current 64-bit microsecond time, stackLimit). But it does not preserve errno. I don't want to avoid calling gettimeofday and can see no harm in it; it's equivalent internally to time providing it doesn't use its TIMEZONE arg (which it doesn't). But the signal handler /doesn't/ preserve errno and doing so is a very good idea and easy to do. Thanks.
Ok, but note that calling a function not on the list of approved functions results in undefined behavior. So, maybe later on you change the optimization level and the VM doesn't work, or you change some other unrelated code and the VM segfaults, etc... maybe it's less painful to just bite the bullet and obey the spec. Andres.
On 11 January 2011 04:42, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Igor, Â Hi All,
On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 3 January 2011 00:15, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Martin, Hi All,    so find new VMs in VM.r2341/.  The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee).  I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet). So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this "fix".  I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground.  Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again.
Eliot, if you remember, i also had crash issues on linux, and pinned down it to removing optimization from <something>heartbeat.c while keeping gcc3x-cointerp.c to use  same optimization flags as for rest of files.
Indeed, quite right.  I happened to add a flag to turn off the heartbeat so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away.  This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does.  I'll try and pass it by someone who's an expert in this area. Anyway, now find a new linux VM in VM.r2346/ that seems fine with the interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2.  Running this VM on CentOS 5.3 under Parallels I get    2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 unexpected passes for the full test suite in Squeak4.2-10856-beta.image. So have at it.
Great! Nice to see that we can deal with elusive bugs :)
best Eliot
I will start coding cmake config for Cog during next week and will be able to check my previous observations again.
best Eliot On Sat, Jan 1, 2011 at 11:16 PM, <mkobetic@gmail.com> wrote:
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 03.01.2011 00:15, Eliot Miranda wrote:
Hi Martin, Hi All,
so find new VMs in VM.r2341/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee). I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet).
So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2). I'm not proud of this "fix". I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground. Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again.
That fixes my Linux crash issues. Cheers Philippe
participants (5)
-
Andres Valloud -
Eliot Miranda -
Igor Stasenko -
mkobetic＠gmail.com -
Philippe Marschall