Stephane Rollandin reported this:
— |
Christian Kellerman reported this:
— |
In reply to this post by David T Lewis
Here is lldb debug report on OSX:
we have :
Wow,
Hmm is that intended to be so large? or just -1? it comes from
We are in the later case:
up the stack, we have:
in b3d.h, we have:
and what is a So it's a bit more subtle than pointer stored into int.
— |
In reply to this post by David T Lewis
I broke it in #448 What I'm very unsure of now, is if writing at negative offset is a good idea (buffer underflow?), or if this uncovers yet another bug at upper level... — |
In reply to this post by David T Lewis
On Fri, Jan 10, 2020 at 1:57 PM Nicolas Cellier <[hidden email]> wrote: > I broke it in #448 > <https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/448> > The function signature was already BADLY inconsistent! > But luckily, the erroneous 64 bits arguments did get copied into 32 bits > dstY before my fix... > I sort of broke the spell and the magic vanished ;) > Brittle code = hazardous life > > What I'm very unsure of now, is if writing at negative offset is a good > idea (buffer underflow?), or if this uncovers yet another bug at upper > level... > If I just correct function signature, the game seems to work though... > That's the right thing to do, no? Just fix the signature. _,,,^..^,,,_ best, Eliot — |
In reply to this post by David T Lewis
Question: where is the BitBlt plugin — |
In reply to this post by David T Lewis
We also have a few UB associated with those negative values Then got:
I do not think that it is the source of problem, but yet another potential problem in the future in case of aggressive C compiler optimization... — |
In reply to this post by David T Lewis
I have removed all this specific UB — |
In reply to this post by David T Lewis
Closed #468. — |
In reply to this post by David T Lewis
> I have removed all this specific UB > I have forbidden writing at negative offset (buffer underrun?) > I think that we can close this one (better than let it open forever if > we are unsure). I have not had a single crash since those last fixes of yours (using VM from Feb 9). Stef |
Great, shall we use that VM for the upcoming Squeak release? Fabio On Mon, 17 Feb 2020 at 8:54 pm, Stéphane Rollandin <[hidden email]> wrote:
|
Hmm, not yet, I'm currently chasing a bug on 32 bits Spur (related to highBit it seems). Le lun. 17 févr. 2020 à 21:07, Fabio Niephaus <[hidden email]> a écrit :
|
In reply to this post by fniephaus
> Great, shall we use that VM for the upcoming Squeak release? Hmm, sorry, I just realized the topic here is about 64bits VM. So far I have not been able to load my game on a 64bits VM (tested with the one from Feb 9). It crashes right away. Stef |
primitiveHighBit problem should be fixed in VMMaker.oscog-nice.2712 It remains to generate all the Spur 32 variants... Le lun. 17 févr. 2020 à 21:35, Stéphane Rollandin <[hidden email]> a écrit :
|
Hem, I did not fix anything, just the simulation of BSR (bit scan reverse) because Bochs seems to initialize an ooold cpu? Most cpu have CLZ (count leading zeros), and Spur32 still crash if activating pimitiveHighBit (575) at image side. We must fix it, i'm pretty sure that it used to work... Le lun. 17 févr. 2020 à 21:58, Nicolas Cellier <[hidden email]> a écrit :
|
Hi Nicolas, On Feb 17, 2020, at 11:31 PM, Nicolas Cellier <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |