Vm-dev March 2011

vm-dev@lists.squeakfoundation.org

43 participants
133 discussions

another problem: Alien+Cog+Linux (Ubuntu 10.4)
by Esteban Lorenzano 08 Mar '11

08 Mar '11

Hi, grrrr... today is a miserably day... none of my tries succeed :(( now... we are trying to use Alien in unix. Using a cog. We are using Cog 2361 We downloaded a Pharo 1.2 We installed Alien, using (ConfigurationOfAlien project version: 'Pharo 1.2') load: #('Core' 'Tests' 'LibC'). We tried: AlienExamples new examplePrintf. and vm crash, with the stack I'm attaching. is anyone using alien in linux? any idea? sorry for so many mails today, but I'm becoming really frustrated :( Thanks, Esteban /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak(error+0x40)[0x805bdf0] [0xf76e6400] /lib32/libc.so.6(_IO_printf+0x30)[0xf7553430] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak(callIA32IntegralReturn+0x184)[0x80ba8e4] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x80b93eb] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x805d305] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x806be34] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak(interpret+0x2415)[0x807a64f] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x807d85b] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x807de24] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak(interpret+0x559c)[0x807d7d6] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak(main+0x36a)[0x805bb1a] /lib32/libc.so.6(__libc_start_main+0xe6)[0xf7522bd6] /home/npasserini/Applications/Pharo/coglinux-r2361/bin/../lib/squeak/3.9-7/squeak[0x8059fb1] Segmentation fault C stack backtrace: Smalltalk stack dump: 0xffe1f068 I LibCLibrary>printfWithArguments: -1218035864: a(n) LibCLibrary 0xffe1f094 I AlienExamples>examplePrintf -1218036484: a(n) AlienExamples 0xffe1f0ac M UndefinedObject>? -1245224956: a(n) UndefinedObject 0xffe1f0e4 I Compiler>evaluate:in:to:notifying:ifFail:logged: -1218569312: a(n) Compiler 0xffe1f124 I [] in SmalltalkEditor>evaluateSelection -1223403976: a(n) SmalltalkEditor 0xffe1f140 M BlockClosure>on:do: -1218569356: a(n) BlockClosure 0xffe1f174 I SmalltalkEditor>evaluateSelection -1223403976: a(n) SmalltalkEditor 0xffe1f194 I SmalltalkEditor>doIt -1223403976: a(n) SmalltalkEditor 0xffe1f1ac M SmalltalkEditor>doIt: -1223403976: a(n) SmalltalkEditor 0xffe1f1dc I SmalltalkEditor(TextEditor)>dispatchOn: -1223403976: a(n) SmalltalkEditor 0xffe1f200 I SmalltalkEditor(TextEditor)>processKeyStroke: -1223403976: a(n) SmalltalkEditor 0xffe1f224 I SmalltalkEditor(TextEditor)>keystroke: -1223403976: a(n) SmalltalkEditor 0xffe1f244 M [] in TextMorphForEditView(TextMorph)>keyStroke: -1223409924: a(n) TextMorphForEditView 0xffe1f268 M TextMorphForEditView(TextMorph)>handleInteraction: -1223409924: a(n) TextMorphForEditView 0xffe1f28c I TextMorphForEditView>handleInteraction: -1223409924: a(n) TextMorphForEditView 0xffe1f2b0 M [] in TextMorphForEditView(TextMorph)>keyStroke: -1223409924: a(n) TextMorphForEditView 0xffe1f2dc I ECToolSet class>codeCompletionAround:textMorph:keyStroke: -1236150044: a(n) ECToolSet class 0xffe1f30c I DEVToolSet class>codeCompletionAround:textMorph:keyStroke: -1235207980: a(n) DEVToolSet class 0xffe1f330 M ToolSet class>codeCompletionAround:textMorph:keyStroke: -1244305988: a(n) ToolSet class 0xffe1f354 M TextMorphForEditView(TextMorph)>keyStroke: -1223409924: a(n) TextMorphForEditView 0xffe1f37c I TextMorphForEditView>keyStroke: -1223409924: a(n) TextMorphForEditView 0xffe1f3a4 I TextMorphForEditView(TextMorph)>handleKeystroke: -1223409924: a(n) TextMorphForEditView 0xffe1f3c0 M KeyboardEvent>sentTo: -1218570456: a(n) KeyboardEvent 0xffe1f3dc M TextMorphForEditView(Morph)>handleEvent: -1223409924: a(n) TextMorphForEditView 0xffe1f3f8 M TextMorphForEditView(Morph)>handleFocusEvent: -1223409924: a(n) TextMorphForEditView 0xffe1f420 M [] in HandMorph>sendFocusEvent:to:clear: -1243842780: a(n) HandMorph 0xffe1f43c M [] in PasteUpMorph>becomeActiveDuring: -1242768520: a(n) PasteUpMorph 0xffe1f458 M BlockClosure>on:do: -1218570508: a(n) BlockClosure 0xffe1f484 M PasteUpMorph>becomeActiveDuring: -1242768520: a(n) PasteUpMorph 0xffe1f4a8 M HandMorph>sendFocusEvent:to:clear: -1243842780: a(n) HandMorph 0xffe1f4d0 M HandMorph>sendEvent:focus:clear: -1243842780: a(n) HandMorph 0xffe1f4f4 M HandMorph>sendKeyboardEvent: -1243842780: a(n) HandMorph 0xffe1f518 M HandMorph>handleEvent: -1243842780: a(n) HandMorph 0xffe1f544 M HandMorph>processEvents -1243842780: a(n) HandMorph 0xffe1f55c M [] in WorldState>doOneCycleNowFor: -1241360348: a(n) WorldState 0xffe1f580 M Array(SequenceableCollection)>do: -1245211280: a(n) Array 0xffe1f59c M WorldState>handsDo: -1241360348: a(n) WorldState 0xffe1f5b8 M WorldState>doOneCycleNowFor: -1241360348: a(n) WorldState 0xffe1f5d4 M WorldState>doOneCycleFor: -1241360348: a(n) WorldState 0xffe1f5f0 M PasteUpMorph>doOneCycle -1242768520: a(n) PasteUpMorph 0xffe1f610 I [] in Project class>? -1241889124: a(n) Project class -1242494908 s [] in BlockClosure>? Most recent primitives at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: species new: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: basicNew: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: basicNew: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at:put: at: * + - at: at: + * + at: at: + * + at: new <= * + at: + * + + at: * + at: at: + * + basicNew size basicNew size bitShift: bitOr: + byteAt:put: bitShift: byteAt:put: bitXor: size species basicNew: replaceFrom:to:with:startingAt: size basicNew: replaceFrom:to:with:startingAt: size replaceFrom:to:with:startingAt: > basicNew: basicNew at:put: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: size at:put: species basicNew: replaceFrom:to:with:startingAt: size size size perform:withArguments: perform:withArguments: perform:withArguments: species new: species new: perform:withArguments: species new: species new: species new: replaceFrom:to:with:startingAt: newMethod:header: size at: at:put: size size objectAt:put: objectAt:put: objectAt:put: objectAt:put: basicNew size objectAt: basicNew objectAt: at:put: at:put: at:put: at:put: value objectAt: size objectAt: objectAt: objectAt: objectAt: objectAt: objectAt:put: objectAt: objectAt:put: withArgs:executeMethod: basicNew basicNew: at:put: species basicNew: replaceFrom:to:with:startingAt: replaceFrom:to:with:startingAt: size basicNew new: basicNew basicIdentityHash at:put: basicNew at:put: basicNew at:put: basicNew at:put: basicNew at:put: new: at:put: at:put: at:put: at:put: at:put: basicNew at:put: basicNew at:put: basicNew at:put: basicNew: sizeFieldPut: Ccalloc: addressFieldPut: replaceFrom:to:with:startingAt: basicNew getSystemAttribute: compare:with:collated: getSystemAttribute: compare:with:collated: getSystemAttribute: compare:with:collated: primLoadLibrary: basicNew: sizeFieldPut: unsignedLongAt:put: sizeField sizeField addressField basicNew: sizeFieldPut: addressFieldPut: + basicNew: sizeFieldPut: primFindSymbol: + basicNew: sizeFieldPut: addressFieldPut: primFFICallResult:withArguments:

3 2

Fwd: [Pharo-project] Issue 1064 in pharo: There are still problem with keyboard shortcuts in Windows
by Mariano Martinez Peck 07 Mar '11

07 Mar '11

Hi, I fordward this thread to the VM mailing list since it looks more appropiated. David, here "tn" is proposing a fix. I am not qualified to take a look. Hope it helps Mariano ---------- Forwarded message ---------- From: <pharo(a)googlecode.com> Date: Sat, Mar 5, 2011 at 9:23 PM Subject: Re: [Pharo-project] Issue 1064 in pharo: There are still problem with keyboard shortcuts in Windows To: pharo-project(a)lists.gforge.inria.fr Comment #14 on issue 1064 by happy.lo...(a)gmail.com: There are still problem with keyboard shortcuts in Windows http://code.google.com/p/pharo/issues/detail?id=1064 Hi, I'm tn. 'ctrl + m' problem is Cog VM bug. Normally, when character key is pushed, keyboard events occur as follows on Squeak. 1. key press (down) 2. character (character code notification) 3. key release (up) They are produced by a primitive method in IutEventFetcher >> primGetNextEvent. But when ctrl + m is pushed, a character event doesn't occur. Because 'ctrl + m' value is 13. The value is same as ENTER key. Cog VM ignores WM_CHAR message(character event) when ENTER key is pushed. The one of solution for this problem is to add CTRL key state to the if-condition. -- sqWin32Window.c -- int recordKeyboardEvent(MSG *msg) { ... switch(msg->message) { ... case WM_CHAR: case WM_SYSCHAR: /* Note: VK_RETURN is recorded as virtual key ONLY */ if(keyCode == 13 && !ctrl) return 1; // add "&& !ctrl" pressCode = EventKeyChar; break; ... } ... Note: ENTER keyCode is 13. But when ctrl + ENTER is pushed, the keyCode is 10. So if the condition is revised, ctrl + m problem is corrected. but other behavior is not changed. If you want to prevent to generate character event for CTRL + ENTER, you can add following code. By this way, we can produce not only ctrl+m (0x0D)'s character event but also ctrl+j (0x0A)'s one. -- sqWin32Window.c -- // add this function static int isNotKeyDownCtrlReturn(MSG* msgp){ if(msgp->message == WM_KEYDOWN && msgp->wParam == VK_RETURN){ if(GetKeyState(VK_CONTROL) & 0x8000) { return FALSE; } } return TRUE; } ... int ioProcessEvents(void) { static MSG msg; ... if(isNotKeyDownCtrlReturn(&msg)){ // add TranslateMessage(&msg); } // add DispatchMessage(&msg); ... } ... int recordKeyboardEvent(MSG *msg) { ... if(pressCode == EventKeyDown && virtCode != 0 && isNotKeyDownCtrlReturn(lastMessage) ) { // add " && isNotKeyDownCtrlReturn(lastMessage) " /* generate extra character event */ ... } return 1; } An attached file is source, which has been corrected by above way. Note: Below is a comment in the source code. /* note: several keys are not reported as character events; most noticably the mapped virtual keys. For those we generate extra character events here */ Those keys(e.g. arrow) should not be ascii code. ENTER key is not. but an extra character events is created for ENTER. I don't think this behavior is correct. As for ENTER key, an extra character event must not be generated, and WM_CHAR message should be processed. Please see MSDN about TranslateMessage. see also Comment 11. Thanks, Attachments: sqWin32Window.c 99 KB

3 2

Re: [squeak-dev] Re: Closure VM on XO
by Levente Uzonyi 07 Mar '11

07 Mar '11

On Sat, 5 Mar 2011, Levente Uzonyi wrote: > On Fri, 4 Mar 2011, Eliot Miranda wrote: > > snip > >> Does the XO Geode support sse2? Actually, what is the exact processor in >> the X0? Right now the JIT won't use sse2 instructions if they aren;t >> available, which translates into no machine code floatng-point primitives. >> But I'm also using sse2 instructions to update the 64-bit microsecond >> clock, so without some rewrite teh current linux Cog does depend on sse2. > > Older XO's have Geode GX, newer have Geode LX CPUs. None of these support SSE > at all, just MMX and an extended version of 3DNow!. There's no MFENCE (just > SFENCE), so an alternative implementation is necessary for these CPUs. According to http://www.linuxjournal.com/node/8212/print mfence is only necessary on x86_64 platforms, so I added the following two lines before the else branch in sqMemoryFence.h # elif !defined(__X86_64__) # define sqLowLevelMFence() asm volatile ("lock; addl $0,0(%%esp)":::"memory") I compiled it with r2361 and it works fine on my 32-bit Ubuntu 10.04. So if the -msse compiler flag is removed from the Makefiles, then Cog should run on the XO-1 too. The article also mentions smp_mb() which should be used on linux, but I couldn't find which header file defines it. Levente > > > Levente > >> >> best >> Eliot > > snip > >

2 2

Re: [Vm-dev] serial plugin crash on unix
by Markus Lampert 07 Mar '11

07 Mar '11

Hi Dave, Thanks for entering the Mantis bug and forwarding the issue. Didn't know the process for vm issues. Next time .... I start to understand how the plugins work. The return value of open and close is actually ignored by the interface code, so the only thing that matter is success(true/false). If I understand the mailing lists correctly I should move the discussion about changing the return value to squeak-dev. Have fun, Markus ----- Original Message ---- > From: David T. Lewis <lewis(a)mail.msen.com> > To: Squeak Virtual Machine Development Discussion ><vm-dev(a)lists.squeakfoundation.org> > Sent: Sun, March 6, 2011 3:46:51 PM > Subject: Re: [Vm-dev] serial plugin crash on unix > > > On Sat, Mar 05, 2011 at 04:00:03PM -0800, Markus Lampert wrote: > > > > Hi, > > > > the serial plugin for unix (4.4.7.2357) can take the vm down. The following >code > > > > > demonstrates the issue: > > > > s := SerialPort new. > > 40 timesRepeat: [ > > s openPort: '/dev/ttyS0'. > > s close] > > > > I have attached a version of sqUnixSerial.c which fixes the problem. It >allows > > > for 32 _different_ serial ports to be opened and closed (as often as >necessary). > > > > > It also prevents the segmentation fault. If more than 32 different serial >ports > > > are attempted to be opened the request fails. > > > > The changes are in line 202, and 220 - 352. > > Thanks Markus, > > This is on Mantis at http://bugs.squeak.org/view.php?id=7610, and I will > forward your fix to Ian also. It looks very good to me although I did not > test it. > > > > > In the current implementation (trunk) it is not possible to find out if > > #openPort: was successful or not and I don't know how to fix that. > > I am not a user of the serial port plugin, but it sounds like this would > be easy to fix. It looks like the support code returns 0 on success and > -1 on failure, so we could pass that back as the result of the primitive, > or return true/false as the result of the primitive call. Would something > like that help? > > Dave > >

1 0

[Fwd: StarMorph busted in Cuis 850 + Cog r2361]
by Juan Vuletich 07 Mar '11

07 Mar '11

Hi Folks, (Steven, I hope you don't mind me forwarding this to public lists) I got this bug report from Steven. It is a problem with Cog. This works ok with the interpreter, but fails with Cog. If I copy this method to Squeak trunk, the same happens. Please see that a message is sent to class Point, but it looks as if the receiver is an instance of Float. See that in the trace, it reads "Float(Point class)>>r:degrees:" which makes no sense at all. It looks like in this case, a pointer is pointing to the wrong object. Something very strange is that evaluating 'StarMorph new openInWorld' seems to work ok, but creating a StarMorph from the 'new morph' menu fails most times (but not always!). Any help from VM gurus is greately appreciated. Just copy the method to Squeak and try. Cheers, Juan Vuletich -------- Original Message -------- As a gesture of appreciation for Cuis, here's a big report of a small bug. :) =========================================== Reproduce via 'Add a new morph' -> Widgets -> StarMorph. =========================================== StarMorph>>initialize from Squeak 4.2 (works) initialize "initialize the state of the receiver" super initialize. self makeVertices: self defaultSides starRatio: self defaultStarRatio withCenter: self defaultCenter withPoint: self defaultFirstVertex. self computeBounds StarMorph>>initialize from Cuis (MNU) initialize "initialize the state of the receiver" | pt ext oldR points | super initialize. "" pt := 10 @ 10. ext := pt r. oldR := ext. points := 5. vertices := (0 to: 359 by: 360 // points // 2) collect: [:angle | (Point r: (oldR := oldR = ext ifTrue: [ext * 5 // 12] ifFalse: [ext]) degrees: angle + pt degrees) + (45 @ 45)]. self computeBounds =========================================== MessageNotUnderstood: Float>>new 6 March 2011 6:43:13.424 am VM: Mac OS - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.47] Croquet Cog 3.0.0 Image: Cuis 3.1 [latest update: #850] Float(Object)>>doesNotUnderstand: #new Receiver: 14.14213562373095 Arguments and temporary variables: aMessage: new exception: MessageNotUnderstood: Float>>new resumeValue: nil Receiver's instance variables: 14.14213562373095 Float(Point class)>>r:degrees: Receiver: 14.14213562373095 Arguments and temporary variables: rho: 14.14213562373095 degrees: 81.0 Receiver's instance variables: 14.14213562373095 [] in StarMorph>>initialize Receiver: a StarMorph(2314)

2 4

serial plugin crash on unix
by Markus Lampert 07 Mar '11

07 Mar '11

Hi, the serial plugin for unix (4.4.7.2357) can take the vm down. The following code demonstrates the issue: s := SerialPort new. 40 timesRepeat: [ s openPort: '/dev/ttyS0'. s close] I have attached a version of sqUnixSerial.c which fixes the problem. It allows for 32 _different_ serial ports to be opened and closed (as often as necessary). It also prevents the segmentation fault. If more than 32 different serial ports are attempted to be opened the request fails. The changes are in line 202, and 220 - 352. In the current implementation (trunk) it is not possible to find out if #openPort: was successful or not and I don't know how to fix that. Have fun, Markus

2 1

Does FFI support WideStrings?
by Mariano Martinez Peck 06 Mar '11

06 Mar '11

Hi. Someone pointed out here: http://stackoverflow.com/questions/5212790/unicode-characters-in-a-smalltal… a problem while using WideStrings with FFI. FFI throws a "Could not coerce arguments". Is this because of the usage of WideString? what we should use instead (I know that ByteString works) ? can we fix FFI so that it supports WideStrings? thanks Mariano

3 2

Re: [Pharo-users] Compiling cog 2363 in gentoo (amd 64)
by Mariano Martinez Peck 06 Mar '11

06 Mar '11

Thanks Panu. It is really nice when people spend time to document and share their findings. I cc'ed the VM mailing list. I don't know why but something tell me that the UUID was finally fixes in latest VMMaker (not sure at all. And even less sure in Cog). Thanks! mariano On Sun, Mar 6, 2011 at 6:25 PM, Panu Suominen <panu.suominen(a)iki.fi> wrote: > So I hit the UUID problem that crashes VM and had to compile virtual > machine from scratch to get rid of it. > I assumed that to be easy job, but it took a while. To help others I > document the steps I had to take to build revision 2363 of Cog vm on > Gentoo (amd 64bit). > 1) fetch sources from svn (svn export > http://squeakvm.org/svn/squeak/branches/Cog cog-vm) > 2) 32bit chroot environment. Just could not make it compile without it > (http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=2) > 3) emerge xorg-x11 to 32bit environment. One could probably emerge > something smaller but thid did the trick for plugin(s) requiring > OpenGL. > 3) configure as the unixbuild/HowToBuild guides. > 4) add #define HAVE_UUID_H to configure.h under bld-directory. > 5) change platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c > #include <uuid.h> -> #include <uuid/uuid.h> > 6) make as the unixbuild/HowToBuild guides > > It is likely that these changes could (and should) be made to the > source files and configuration script so that no manual steps would be > required. However I did not have time to do it. But when I finnish all > the pending tasks postponed by this sideroute I try to see > if I could propose a patch. > > -- > Panu > >

2 1

[commit] r2363 - Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in heartbeat.
by commits＠squeakvm.org 06 Mar '11

06 Mar '11

Author: eliot Date: 2011-03-02 09:29:55 -0800 (Wed, 02 Mar 2011) New Revision: 2363 Modified: branches/Cog/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c branches/Cog/platforms/unix/vm/Makefile.in branches/Cog/platforms/unix/vm/sqUnixHeartbeat.c Log: Merge Levente's linux UUIDPlugin fix. Fix tickerSleepCycle decl in heartbeat. Restore -O2 optimization for the interpreter. Modified: branches/Cog/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c =================================================================== --- branches/Cog/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c 2011-02-16 05:52:50 UTC (rev 2362) +++ branches/Cog/platforms/unix/plugins/UUIDPlugin/sqUnixUUID.c 2011-03-02 17:29:55 UTC (rev 2363) @@ -1,18 +1,80 @@ -#include <uuid/uuid.h> +#include "config.h" + +#if defined(HAVE_SYS_UUID_H) +# include <sys/types.h> +# include <sys/uuid.h> +#endif +#if defined(HAVE_UUID_H) + #include <uuid.h> +#endif + #include "sq.h" -int sqUUIDInit(void) { return 1; } -int sqUUIDShutdown(void) { return 1; } - int MakeUUID(char *location) { uuid_t uuid; -#if defined(__NetBSD__) + +#if defined(HAVE_UUIDGEN) uuidgen(&uuid, 1); -#else +#elif defined(HAVE_UUID_GENERATE) uuid_generate(uuid); #endif + memcpy((void *)location, (void *)&uuid, sizeof(uuid)); return 1; } + + +#if defined(__linux__) + +# include <setjmp.h> +# include <signal.h> + +static sigjmp_buf env; + +static void sigsegvHandler(int signal) +{ + siglongjmp(env, 1); +} + +int sqUUIDInit(void) +{ + /* check if we get a segmentation fault when using libuuid */ + int pluginAvailable= 0; + struct sigaction originalAction; + uuid_t uuid; + + if (!sigsetjmp(env, 1)) + { + struct sigaction newAction; + newAction.sa_handler= sigsegvHandler; + newAction.sa_flags= 0; + sigemptyset(&newAction.sa_mask); + + if (sigaction(SIGSEGV, &newAction, &originalAction)) + /* couldn't change the signal handler: give up now */ + return 0; + else + pluginAvailable= MakeUUID((char *)&uuid); + } + + sigaction(SIGSEGV, &originalAction, NULL); + + return pluginAvailable; +} + +#else /* !__linux__ */ + +int sqUUIDInit(void) +{ + return 1; +} + +#endif /* !__linux__ */ + + +int sqUUIDShutdown(void) +{ + return 1; +} Modified: branches/Cog/platforms/unix/vm/Makefile.in =================================================================== --- branches/Cog/platforms/unix/vm/Makefile.in 2011-02-16 05:52:50 UTC (rev 2362) +++ branches/Cog/platforms/unix/vm/Makefile.in 2011-03-02 17:29:55 UTC (rev 2363) @@ -71,13 +71,13 @@ # Ensure the heartbeat is compiled with less aggressive optimization. At # least with gcc 4.1.2 compiling with -O2 results in an apparently flakey VM; # so flakey the Squeak4.2-10856-beta.image image won't even start-up. -sqUnixHeartbeat$o : $(topdir)/platforms/unix/vm/sqUnixHeartbeat.c - $(COMPILE) sqUnixHeartbeat$o -O1 -fno-omit-frame-pointer -mno-rtd -mno-accumulate-outgoing-args $(topdir)/platforms/unix/vm/sqUnixHeartbeat.c +#sqUnixHeartbeat$o : $(topdir)/platforms/unix/vm/sqUnixHeartbeat.c +# $(COMPILE) sqUnixHeartbeat$o -O1 -fno-omit-frame-pointer -mno-rtd -mno-accumulate-outgoing-args $(topdir)/platforms/unix/vm/sqUnixHeartbeat.c # Ensure the cointerpreter is compiled with less aggressive optimization. At # least with gcc 4.1.2 compiling with -O2 results in an apparently flakey VM. -gcc3x-cointerp$o : $(srcdir)/vm/gcc3x-cointerp.c - $(COMPILE) gcc3x-cointerp$o -O1 -fno-omit-frame-pointer -momit-leaf-frame-pointer -mno-rtd -mno-accumulate-outgoing-args $(srcdir)/vm/gcc3x-cointerp.c +#gcc3x-cointerp$o : $(srcdir)/vm/gcc3x-cointerp.c +# $(COMPILE) gcc3x-cointerp$o -O1 -fno-omit-frame-pointer -momit-leaf-frame-pointer -mno-rtd -mno-accumulate-outgoing-args $(srcdir)/vm/gcc3x-cointerp.c # Ensure the cogit is compiled with less aggressive optimization. The cogit # contains a function that does two alloca's which is miscompiled by a number of Modified: branches/Cog/platforms/unix/vm/sqUnixHeartbeat.c =================================================================== --- branches/Cog/platforms/unix/vm/sqUnixHeartbeat.c 2011-02-16 05:52:50 UTC (rev 2362) +++ branches/Cog/platforms/unix/vm/sqUnixHeartbeat.c 2011-03-02 17:29:55 UTC (rev 2363) @@ -377,7 +377,7 @@ tickCheckInProgress = 0; } -static void +static void * tickerSleepCycle(void *ignored) { struct timespec naptime; @@ -387,6 +387,7 @@ while (1) (void)nanosleep(&naptime, 0); + return 0; } /* We require the error check because we're lazy in preventing multiple

2 2

vm crash building cocoa cog with latest cog sources
by Esteban Lorenzano 04 Mar '11

04 Mar '11

Hi, well... finally I have a cocoa cog build with latest cog sources... but the vm is crashing with this problem: #0 relocateIfCallOrMethodReferencemcpcdelta (annotation=7, mcpc=0x1f41ef0b "\376\377=`h^\037\273", delta=-92792) at /Users/MAC/Desktop/Dev/VM/cog-osx/build/../src/vm/cogit.c:13732 #1 0x0000b74f in relocateMethodsPreCompaction [inlined] () at /Users/MAC/Desktop/Dev/VM/cog-osx/src/vm/cogit.c:12288 #2 0x0000b74f in compactCogCompiledCode () at /Users/MAC/Desktop/Dev/VM/cog-osx/build/../src/vm/cogit.c:3058 I know this problem was reported before, but I thought the bug was fixed... so maybe I'm forgetting something. I'm generating sources with latest CMakeVMMaker, and using this version: VMMaker-oscog-IgorStasenko.Stasenko.49 (which is merged with oscog.47) I'm missing something? Cheers, Esteban

3 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2011