Interestingly, when I recompile on MacOSX, the bug happens on fast version of squeak.stack.v3 but not on debug version!!! That means that it's vain to track the problem with VM simulator. It's also vain to try debugging at C level...
What remains is: Use lldb the unstripped fast version, put a break point in some arithmetic primitive then stepi into assembly. Or carefully inspect the compiler warnings (with ./mvm -- WARNINGS='-Wall -Wextra') and carefully read generated C code to track for a possible undefined behavior striking. Or compare generated C code with generated C assembly to understand what's going on. Or instrument the generated code with undefined behavior guards (I don't remember the clang incantation for that, but it's possible).
2016-09-02 22:09 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Hi Laura, it sounds like some LargeIntegers arithmetic is broken in v3... The clock symptoms is just a side effect.
2016-09-02 21:23 GMT+02:00 Laura Perez Cerrato < lauraperezcerrato@gmail.com>:
Hello everyone,
Lately, while working on the VM, I noticed that a few primitives related with the clock on V3 were returning incorrect values. Cloning the repository and building a Squeak Cog V3 VM produces a VM in which DateAndTime class>>#now answers a value closer than a day to the epoch in both Squeak 4.5 and the lastest version of Cuis. In the lastest version of Cuis, Time class>>#primLocalMicrosecondClock, Time class>>#primLocalSecondClock and Time class>>#primHighResClock return odd values. This problem is seen exclusively on V3 VMs as far as I can tell, independently of the interpreter.
I wasn't capable of pinning down the reason for this strange behaviour. If anyone could give me a hand with that, I'd appreaciate it.
Cheers!
-Laura Perez Cerrato