On 02.01.2011 16:50, Eliot Miranda wrote:
> Hi Philippe, > > what image, what OS and what directories are the vm and image > installed in (yes it can make a difference). - Pharo 1.1.1 - $uname -a Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux - image lies in some subdirectory of the user home, Cog is extracted in the same folder, so it's under coglinux/ Cheers Philippe |
Hi All,
looks like there are issues running Cog on 64-bit linux. I only have a 32-bit one to hand so it'll be a while before I can look at this. BTW, it would really help if when people post bugs they give
- a URL to the image and changes, not just a name like Pharo 1.1.1. A pointer to the exact bits eliminates any possibility that I will fetch the wrong image and not be able to reproduce - the exact directory something is installed in, not just the name but the full path, and whether it is remote ounted or not. I just fixed a crash on windows for Torsten that didn't show on a remote-mounted drive but caused a hard crash if installed as c:\pharo. So saying "its in coglinux/" isn;t being precise enough.
TIA best Eliot
On Sun, Jan 2, 2011 at 11:01 AM, Philippe Marschall <[hidden email]> wrote:
|
In reply to this post by mkobetic
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.
best Eliot On Sat, Jan 1, 2011 at 11:16 PM, <[hidden email]> 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: |
On 3 January 2011 00:15, Eliot Miranda <[hidden email]> 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, <[hidden email]> wrote: -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Eliot Miranda-2
"Eliot Miranda"<[hidden email]> wrote:
> so find new VMs in > VM.r2341/<http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>. Yup, much better on my end. Thanks! Martin |
In reply to this post by Eliot Miranda-2
That sounds familiar... are there bitfields next to a memory allocation
zone boundary? GCC will issue read instructions that read off the bitfield (documented in the manual --- can't really complain), so you can get a segfault reading a bitfield if GCC emits instructions at compile time that read off the allocation edge at run time... On 1/2/11 10:09 , Eliot Miranda wrote: > Hi All, > > looks like there are issues running Cog on 64-bit linux. I only > have a 32-bit one to hand so it'll be a while before I can look at this. > > BTW, it would really help if when people post bugs they give > - a URL to the image and changes, not just a name like Pharo 1.1.1. A > pointer to the exact bits eliminates any possibility that I will fetch > the wrong image and not be able to reproduce > - the exact directory something is installed in, not just the name but > the full path, and whether it is remote ounted or not. I just fixed a > crash on windows for Torsten that didn't show on a remote-mounted drive > but caused a hard crash if installed as c:\pharo. So saying "its in > coglinux/" isn;t being precise enough. > > TIA > > > best > Eliot > > On Sun, Jan 2, 2011 at 11:01 AM, Philippe Marschall <[hidden email] > <mailto:[hidden email]>> wrote: > > On 02.01.2011 16:50, Eliot Miranda wrote: > > Hi Philippe, > > > > what image, what OS and what directories are the vm and image > > installed in (yes it can make a difference). > > - Pharo 1.1.1 > - $uname -a > Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010 > x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux > - image lies in some subdirectory of the user home, Cog is extracted in > the same folder, so it's under coglinux/ > > Cheers > Philippe > > > |
In reply to this post by Mariano Martinez Peck
The MethodContext>>numArgs is I guess to be expected because there's no implementation so far. Find attached.
'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 2 January 2011 at 2:23:32 pm'!
!MethodContext methodsFor: 'accessing' stamp: 'eem 1/2/2011 14:23'! numArgs "Answer the number of arguments required to evaluate this method or block."
^closureOrNil ifNil: [method numArgs] ifNotNil: [closureOrNil numArgs]! ! On Sun, Jan 2, 2011 at 2:49 AM, Mariano Martinez Peck <[hidden email]> wrote: Hi Eliot. Running: MethodContext-numArgs.st (450 bytes) Download Attachment |
In reply to this post by Eliot Miranda-2
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 |
In reply to this post by Eliot Miranda-2
Thanks
http://code.google.com/p/pharo/issues/detail?id=3504 Stef On Jan 3, 2011, at 8:38 PM, Eliot Miranda wrote: > The MethodContext>>numArgs is I guess to be expected because there's no implementation so far. Find attached. > > 'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 2 January 2011 at 2:23:32 pm'! > > !MethodContext methodsFor: 'accessing' stamp: 'eem 1/2/2011 14:23'! > numArgs > "Answer the number of arguments required to evaluate this method or block." > > ^closureOrNil ifNil: [method numArgs] ifNotNil: [closureOrNil numArgs]! ! > > > On Sun, Jan 2, 2011 at 2:49 AM, Mariano Martinez Peck <[hidden email]> wrote: > Hi Eliot. Running: > > - Mac OS > - VM r2340 > - PharoCore 1.2 12288 > > Running all tests I got this DNU. > It is reproducable running the test testClosureRestart which seems to pass well in previous VMs. > > Cheers > > Mariano > > THERE_BE_DRAGONS_HERE > MessageNotUnderstood: MethodContext>>numArgs > 2 January 2011 11:38:31 am > > VM: Mac OS - intel - 1065 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.41] Croquet Cog 3.0.0 > Image: Pharo1.2beta [Latest update: #12288] > > SecurityManager state: > Restricted: false > FileAccess: true > SocketAccess: true > Working Dir /Users/mariano/Pharo/imagenes/PharoCore-1.2beta-12283 > Trusted Dir /foobar/tooBar/forSqueak/bogus/ > Untrusted Dir /Users/mariano/Library/Preferences/Croquet/Internet/Untrusted > > MethodContext(Object)>>doesNotUnderstand: #numArgs > Receiver: [| b | > self assert: 10 == a. > self assert: nil == b. > b := a + 20. > firstTimeThrough > ifT...etc... > Arguments and temporary variables: > t1: numArgs > t2: nil > t3: nil > Receiver's instance variables: > sender: nil > pc: nil > stackp: 3 > method: (MethodContextTest>>#privRestartBlockTest "a CompiledMethod(700186624)"...etc... > closureOrNil: [| b | > self assert: 10 == a. > self assert: nil == b. > b := a + 20...etc... > receiver: MethodContextTest>>#testClosureRestart > > > > --- The full stack --- > MethodContext(Object)>>doesNotUnderstand: #numArgs > ------------------------------------------------------------ > > > > > On Sun, Jan 2, 2011 at 8:52 AM, Philippe Marschall <[hidden email]> wrote: > On 01.01.2011 21:38, Eliot Miranda wrote: > > Hi All, > > > > there are new versions of both the SimpleStackBasedCogit and the > > StackToRegisterMappingCogit Cog VMs in VM.r2337/ > > <http://www.mirandabanda.org/files/Cog/VM/VM.r2337/> & VM.r2338/ > > <http://www.mirandabanda.org/files/Cog/VM/VM.r2338/> respectively. > > These contain fixes for another bad pc mapping bug that could cause > > hard crashes when jitting on a backward branch in a looping interpreted > > method. If you're trying to reproduce Cog crashes please upgrade to one > > of tthese two VMs. > > > > TIA > > and happy new 2011, P.S. according to an FBF > > RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11 > > consecutive prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211 > > Crashes right at start up: > > Segmentation fault > > > > Smalltalk stack dump: > 0xff8aafb4 M Error class(Exception class)>handles: -1246542340: a(n) > Error class > 0xff8aafdc M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) > MethodContext > 0xff8aaffc M MethodContext(ContextPart)>handleSignal: -1216945468: a(n) > MethodContext > 0xff8ab020 I UnhandledError(Exception)>signal -1216945236: a(n) > UnhandledError > 0xff8ab040 I UnhandledError class>signalForException: -1246541380: a(n) > UnhandledError class > 0xff8ab064 I MessageNotUnderstood(Error)>defaultAction -1216945688: a(n) > MessageNotUnderstood > 0xff8ab084 I MessageNotUnderstood>defaultAction -1216945688: a(n) > MessageNotUnderstood > 0xff8ab0a8 I UndefinedObject>handleSignal: -1247481852: a(n) UndefinedObject > 0xff8ab0cc I MessageNotUnderstood(Exception)>pass -1216945688: a(n) > MessageNotUnderstood > 0xff8ab0f8 I [] in PasteUpMorph>becomeActiveDuring: -1245846436: a(n) > PasteUpMorph > 0xff8ab11c I BlockClosure>valueWithPossibleArgs: -1221000224: a(n) > BlockClosure > 0xff8ab13c M [] in MethodContext(ContextPart)>handleSignal: -1220670568: > a(n) MethodContext > 0xff8ab15c M BlockClosure>ensure: -1216945284: a(n) BlockClosure > 0xff8ab17c M MethodContext(ContextPart)>handleSignal: -1220670568: a(n) > MethodContext > 0xff8ab1a4 I MethodContext(ContextPart)>handleSignal: -1216945468: a(n) > MethodContext > 0xff8ab1c8 I MessageNotUnderstood(Exception)>signal -1216945688: a(n) > MessageNotUnderstood > 0xff8ab1f0 I ProcessorScheduler(Object)>doesNotUnderstand: >= > -1247476532: a(n) ProcessorScheduler > 0xff8ab210 M Process>priority: -1216945752: a(n) Process > 0xff8ab238 I BlockClosure>forkAt: -1216945972: a(n) BlockClosure > 0xff8ab25c I > InputEventPollingFetcher(InputEventFetcher)>installEventLoop > -1246030580: a(n) InputEventPollingFetcher > 0xff8ab280 I InputEventPollingFetcher(InputEventFetcher)>startUp > -1246030580: a(n) InputEventPollingFetcher > 0xff8ab2a0 I InputEventFetcher class>startUp -1246046280: a(n) > InputEventFetcher class > 0xff8ab2b8 M InputEventFetcher class(Behavior)>startUp: -1246046280: > a(n) InputEventFetcher class > 0xff8ab2e0 M [] in SmalltalkImage>send:toClassesNamedIn:with: > -1242015264: a(n) SmalltalkImage > 0xff8ab2fc M BlockClosure>on:do: -1216946688: a(n) BlockClosure > 0xff8ab32c M [] in SmalltalkImage>send:toClassesNamedIn:with: > -1242015264: a(n) SmalltalkImage > 0xff8ab354 I OrderedCollection>do: -1241999736: a(n) OrderedCollection > 0xff8ab37c I SmalltalkImage>send:toClassesNamedIn:with: -1242015264: > a(n) SmalltalkImage > 0xff8ab3a8 I SmalltalkImage>processStartUpList: -1242015264: a(n) > SmalltalkImage > 0xff8ab3d4 I SmalltalkImage>snapshot:andQuit:embedded: -1242015264: a(n) > SmalltalkImage > -1220672224 s SmalltalkImage>snapshot:andQuit: > -1220672132 s WorldState class>saveAndQuit > -1220672040 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > -1220671948 s BlockClosure>ensure: > -1220999860 s CursorWithMask(Cursor)>showWhile: > -1220999972 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent: > -1220671856 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp: > -1220671764 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp: > -1220671672 s MouseButtonEvent>sentTo: > -1220671580 s ToggleMenuItemMorph(Morph)>handleEvent: > -1220671488 s MorphicEventDispatcher>dispatchDefault:with: > -1220671396 s MorphicEventDispatcher>dispatchEvent:with: > -1220671304 s ToggleMenuItemMorph(Morph)>processEvent:using: > -1220671212 s MorphicEventDispatcher>dispatchDefault:with: > -1220671120 s MorphicEventDispatcher>dispatchEvent:with: > -1220671028 s MenuMorph(Morph)>processEvent:using: > -1220670936 s MenuMorph(Morph)>processEvent: > -1220670844 s MenuMorph>handleFocusEvent: > -1220670752 s [] in HandMorph>sendFocusEvent:to:clear: > -1220670660 s [] in PasteUpMorph>becomeActiveDuring: > -1220670568 s BlockClosure>on:do: > -1221000336 s PasteUpMorph>becomeActiveDuring: > -1221000456 s HandMorph>sendFocusEvent:to:clear: > -1220670476 s HandMorph>sendEvent:focus:clear: > -1221000572 s HandMorph>sendMouseEvent: > -1221000664 s HandMorph>handleEvent: > -1220670384 s HandMorph>processEvents > -1220670292 s [] in WorldState>doOneCycleNowFor: > -1220670200 s Array(SequenceableCollection)>do: > -1220670108 s WorldState>handsDo: > -1221001008 s WorldState>doOneCycleNowFor: > -1220670016 s WorldState>doOneCycleFor: > -1220669924 s PasteUpMorph>doOneCycle > -1221589100 s [] in Project class>spawnNewProcess > -1221602884 s [] in BlockClosure>newProcess > > Most recent primitives > basicNew > size > at: > basicNew: > decompress:fromByteArray:at: > beCursorWithMask: > vmParameterAt:put: > vmParameterAt:put: > setGCBiasToGrowGCLimit: > setGCBiasToGrow: > ensure: > valueNoContextSwitch > wait > value > specialObjectsArray > new: > at:put: > value > signal > basicNew > new: > at: > value: > basicIdentityHash > on:do: > value > perform:with: > millisecondClockValue > signal > value: > size > size > bitShift: > \\ > \\ > \\ > \\ > \\ > perform:with: > shallowCopy > subclasses > new: > new: > new: > // > value: > value: > value: > = > = > value: > value: > at:put: > value: > at:put: > addAll: > - > + > + > + > size > at: > do: > do: > value: > getSystemAttribute: > compare:with:collated: > value: > value: > platformName > = > = > value: > value: > getSystemAttribute: > compare:with:collated: > determineActivePlatformStartingAt: > determineActivePlatformStartingAt: > basicNew > value: > value: > value: > value: > perform:with: > actualScreenSize > species > species > supportsDisplayDepth: > new: > basicNew > beDisplay > value: > perform:with: > isMemberOf: > value: > perform:with: > basicNew > critical: > critical: > wait > wait > specialObjectsArray > species > new: > replaceFrom:to:with:startingAt: > specialObjectsArray > at:put: > at:put: > primSetInputSemaphore: > suspend > findNextUnwindContextUpTo: > value: > bottomContext > objectAt: > basicNew: > basicNew > basicNew > findNextHandlerContextStarting > tempAt: > nextHandlerContext > handleSignal: > isKindOf: > tempAt:put: > tempAt:put: > tempAt:put: > valueWithArguments: > findNextHandlerContextStarting > basicNew > findNextHandlerContextStarting > tempAt: > findNextHandlerContextStarting > tempAt: > Abgebrochen > > Cheers > Philippe > > > > > <MethodContext-numArgs.st> |
In reply to this post by Eliot Miranda-2
Hi All,
find new VMs in VM.r2344/ (SimpleStackBasedCogit) and VM.r2345/ (StackToRegisterMappingCogit) and VMMaker-oscog-45. These fix a bug that could cause crashes when converting an interpreted method to a machine-code method on backward branch (i.e. when the Vm detects an interpreted method is looping).
I hope there are no new issues with VM.r2344/ (SimpleStackBasedCogit). However, Matthew Fulmer has found that on linux the VM.r2343/ VM.r2345/ (StackToRegisterMappingCogit) VMs crash immediately loading Squeak4.2-10856-beta.image. I can reproduce this but haven't had time to investigate. The StackToRegisterMappingCogit VMs do start up this image on Mac and Windows.
Agan thanks for pounding on these. I may not be able to attend to the linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next weekend. Apologies. best
Eliot On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote: Hi All, |
In reply to this post by Igor Stasenko
Hi Igor, Hi All,
On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <[hidden email]> 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.
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. best Eliot
|
> 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. |
In reply to this post by Eliot Miranda-2
On 11 January 2011 04:42, Eliot Miranda <[hidden email]> wrote:
> Hi Igor, Hi All, > > On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 3 January 2011 00:15, Eliot Miranda <[hidden email]> 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, <[hidden email]> wrote: >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Andres Valloud-4
On Mon, Jan 10, 2011 at 11:31 PM, Andres Valloud <[hidden email]> wrote:
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.
|
In reply to this post by Eliot Miranda-2
On 10.01.2011 01:28, Eliot Miranda wrote:
> Hi All, > > find new VMs in VM.r2344/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit) > and VM.r2345/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) > and VMMaker-oscog-45. These fix a bug that could cause crashes when > converting an interpreted method to a machine-code method on backward > branch (i.e. when the Vm detects an interpreted method is looping). > > I hope there are no new issues with VM.r2344/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit). > However, Matthew Fulmer has found that on linux the VM.r2343/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> VM.r2345/ > <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit) > VMs crash immediately loading Squeak4.2-10856-beta.image. I can > reproduce this but haven't had time to investigate. > The StackToRegisterMappingCogit VMs do start up this image on Mac and > Windows. > > Agan thanks for pounding on these. I may not be able to attend to the > linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next > weekend. Apologies. r2346 fixes the issues I sometimes had with when the stack would be messed up the first time a method is executed. Cheers Philippe |
In reply to this post by Eliot Miranda-2
Hi All,
I've uploaded new VMs to VM.r2348/ (SimpleStackBasedCogit) and VM.r2349/ (StackToRegisterMappingCogit). The former are simply to be up-to-date with svn & Monticello. The latter also fix a bad bug with the StackToRegisterMappingCogit where e.g. 16r10 bitOr: 16r20 would evaluate to 1. I've smoke-tested the 2349 VMs on the Squeak4.2 beta test suite and things look good.
best Eliot
|
In reply to this post by Eliot Miranda-2
> 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. |
Free forum by Nabble | Edit this page |