Updates:
Status: Done
Comment #3 on issue 13 by esteba...(a)gmail.com: [ENH] Disable module loading
support
http://code.google.com/p/cog/issues/detail?id=13
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
Comment #6 on issue 92 by nicolas....(a)gmail.com: 3 LargeInteger arithmetic
primitive bugs with minimum signed 64 bit value
http://code.google.com/p/cog/issues/detail?id=92
As long as SmallInteger minVal negated (2^30) fits on 32 bits, there would
be no such problem in SmallInteger primitives.
AFAICT, 0 - INT_MIN like problem was only in LargeInt primitives, and those
are not jitted.
However, JIT is clever and for example in genPrimitiveAdd avoid shifting
the SmallInteger tag (genShiftAwaySmallIntegerTagsInScratchReg:), and just
remove it from one of operands (genRemoveSmallIntegerTagsInScratchReg:) so
as to directly produce a tagged integer. Thus, testing if the result fits
in 31 bit SmallInteger, become as simple as testing for 32 bit overflow...
Testing for overflow is much simpler than in C, see senders of
#JumpOverflow:
Note that genPrimitiveDivide use another strategy for testing overflow case
of (SmallInteger minVal/-1).
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 109 by jonkande...(a)gmail.com: CogVM crashes with simple code
http://code.google.com/p/cog/issues/detail?id=109
Below are a few lines of code that crashes the CogVM on both
Linux and Windows. File-in the Smalltalk code below, then evaluate
[nil crashCogVM]. The code uses [1-1] but it could use [1+1] or
[56+98]. I put the code on nil, but that is not important either. I
think the important thing is that the primitive (+ or -) is evaluated
but the result is not assigned into any variable. Also important is
that the code is put into a loop that I assume has been JIT optimized.
The image I used is Pharo 1.4 one-click with latest update #14459.
This code does not crash StackVM.
!UndefinedObject methodsFor: 'crash' stamp: 'JonKAnderson 11/29/2012 17:26'!
crashCogVM
" Evaluate [
nil crashCogVM ]"
| i |
i := 20.
1 to: i do: [:d | 1-1 ]
! !
Updates:
Status: Done
Comment #3 on issue 27 by esteba...(a)gmail.com: Add a new primitive:
#primitiveImageFormatVersion
http://code.google.com/p/cog/issues/detail?id=27
(No comment was entered for this change.)
--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings
at http://www.mirandabanda.org/files/Cog/VM/VM.r2701/.
CogVM binaries as per VMMaker.oscog-eem.272/r2701.
Fix unknownBytecode processing to leave pc at unknown bytecode.
Fix case of process switch to an interior frame.
Fix some assert function signatures in the stack vm.
Use symbols for types instead of strings in stack page funcs.
Fix the become issue where methods that are identical are failing
the code test because their penultimate literals are different objects.
Add a flag "cmUsesPenultimateLit" to jitted methods, stealing bits
from stackCheckOffset (which was way larger than needed).
Shrink stackCheckOffset to 12 bits (still an order of magnitude larger
than needed) and add an error check on assigning it.
Also add a check for max method size (2^16-1 bytes) and refuse to
jit a method that generates too much code.
When comparing code, use the cmUsesPenultimateLit flag to decide
if comparison includes penultimate lit or not.
This is mildly insane, but the VM really doesn't know about the
penultimate literal and it shouldn't depend on knowing it can be
ignored. Note that the CoInterpreter knows about the last literal;
it uses this in supersends. With this hack, Pharo's condenseSources
works.
--
best,
Eliot
On Sun, Mar 10, 2013 at 12:10 PM, Nicolas Cellier
<nicolas.cellier.aka.nice(a)gmail.com> wrote:
> OK, see the VM thread, I now think that problems does not come from
> COG, but from ClassBuilder which in some cases fail to clean a cache
> (primitive 116).
> The problem does not show up in interpreter VM thanks to primitive 119
> (this primitives does not unlink send in cogit).
it does unlink sends, but only for that selector. But is it really
the case that it is a missing cache flush or is it a bug in Cog with
its cache flushing? I realised the way to test this is to try the
Stack VM and see if it crashes or not. I just tried that but now
neither Cog nor the Stack VM crash although both fail the load with an
MNU of #do: to UndefinedObject in Environment>>bindingOf:ifAbsent:.
So how do I get the system back to a state where I can reproduce the
Cog crash to compare the Stack and Cog VMs with each other?
(Apologies for being unresponsive; I've just moved into a new
apartment and only got my internet connection yesterday afternoon; at
least its fast (for the states) :) ).
> I have attempted a ClassBuilder fix and posted new updates from
> nice-222 to cwp-227.
>
> Can I please ask our testers contribution once again?
>
> Nicolas
>
> 2013/3/8 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>:
>> 2013/3/8 Bert Freudenberg <bert(a)freudenbergs.de>:
>>>
>>> On 2013-03-08, at 10:55, Frank Shearar <frank.shearar(a)gmail.com> wrote:
>>>
>>>> On 7 March 2013 23:25, Frank Shearar <frank.shearar(a)gmail.com> wrote:
>>>>> On 7 March 2013 23:11, Bert Freudenberg <bert(a)freudenbergs.de> wrote:
>>>>>> On 2013-03-07, at 23:42, Frank Shearar <frank.shearar(a)gmail.com> wrote:
>>>>>>
>>>>>>>>> On 6 March 2013 15:59, Ken G. Brown <kbrown(a)mac.com> wrote:
>>>>>>>>>> Running on COG 2397, and after updating fresh Squeak4.4-12327 Release to
>>>>>>>>>> 12332, updating to Trunk fails at first attempt in the same place, then by
>>>>>>>>>> abandoning and trying the update again, it apparently completes to 12511.
>>>>>>>>>>
>>>>>>>>>> Ken G. Brown
>>>>>>>>>>
>>>>>>>>>>> With COG 2678, pretty well the same. First attempt it timed out during
>>>>>>>>>>> the same update-nice-223, then trying again from what had already been
>>>>>>>>>>> loaded, got the following during the same update, during compiling
>>>>>>>>>>> SMLoader-fbs-78 as before:
>>>>>>>
>>>>>>> What I find strange about all this is that we take a 4.4-12327 image
>>>>>>> and whatever the latest Cog is and update it all the way without any
>>>>>>> probems quite a few times a day on the CI server.
>>>>>>>
>>>>>>> frank
>>>>>>
>>>>>> Looks like it's an intermittent problem, unfortunately:
>>>>>>
>>>>>> I just updated the new all-in-one-cog to latest trunk, no problem. This is a 4.4-12327 image with Cog VM 2697.
>>>>>>
>>>>>> I then tried what Ken described: update the fresh image first from the squeak44 stream, then switch to trunk, then update again.
>>>>>>
>>>>>> BOOM. Cog crash. Didn't save the log unfortunately.
>>>>>>
>>>>>> Tried again. Update, switch to trunk, update again. No crash. What?!
>>>>>>
>>>>>> Once more. Update, switch to trunk, update. Crash! See below.
>>>>>>
>>>>>> Tried yet again, with switching to trunk immediately in a fresh image. Crashes, too, same place.
>>>>>>
>>>>>> So it does crash, just not always. But it's been more than 50% in my case.
>>>>>
>>>>> Ah, interesting. The CI jobs, naturally, don't update from squeak44;
>>>>> they switch to trunk and update just like that. Which I would have
>>>>> thought would make no difference...
>>>>
>>>> Actually, I lie. Here's an example of the CI jobs hitting the same
>>>> issue: http://build.squeak.org/job/SqueakTrunk/204/console And further
>>>> if you look at http://build.squeak.org/job/SqueakTrunk/ and choose to
>>>> see the failing tests you'll see times (say around build #184) where
>>>> the test failure count is unusually low. And
>>>> http://build.squeak.org/job/SqueakTrunk/buildTimeTrend shows grey
>>>> streaks where builds die.
>>>
>>> Curious that it still runs the tests at all if the update failed ...
>>>
>>> So Cog crashes, but has someone tried to replicate this on an interpreter?
>>>
>>> - Bert -
>>>
>>
>> I think that the problem comes form COG which tries to use an obsolete
>> method sent AFTER the recompilation of Parser which is not the
>> expected behavior.
>> I have triggered such kind of strange behavior that does not happen on
>> an Interpreter VM, see the thread opened by Jeff Gonis '[Vm-dev] Cog
>> VM Crash on Windows'
>> For me, it must be related to a cache that is not cleaned-up, I don't know why.
>>
>> Nicolas
>
--
best,
Eliot