On 28 September 2012 22:32, Eliot Miranda eliot.miranda@gmail.com wrote:
On Fri, Sep 28, 2012 at 8:55 AM, Igor Stasenko siguctua@gmail.com wrote:
Hi,
if i build a debug version of VM on windows , it spams me with this assertion failed in debug console window:
(getfp() & STACK_ALIGN_MASK) == STACK_FP_ALIGN_BYTES 41946 ....
what is this number '41946', which follows? sometimes it is 42015 (and sometimes other), but most of times it's 41946.
It is the line number of the assert that is failing. This will be in the interpreter file somewhere. This is not spam. It is a bug (and likely in NativeBoost).
By spamming i meant "producing a lot of messages". It writes assertions every time i move mouse, which makes a mouse cursor to disappear due to constant writing to console... And of course, assertion failures should be treated seriously.. since people usually put them on purpose :)
Actual question, how i can instruct gdb to break on a first failure of this assertion, so i can catch who causing this (or at least get close to one who causing it)..
wot Mariano said.
Thanks, i'll try to locate the source of bug.
P.S. the STACK_ALIGN_BYTES is 16
P.P.S. i wonder for how long this thing broken there, since we're not building/using debug version of VM that often.
I doubt it is broken in the VM. Stack alignment is very important for e.g. SSE floating-point on x86. If it were broken the VM would not work. I guess you're generating NB code that is not preserving stack alignment and on callback you're falling foul of the assert.
Heh.. things would be much much easier if it would be my code. The problem is that i running fresh image, without NB installed, so there's no chance that i can screw things with own generated code. It must be something in VM.
Btw, if remember before, i reported problems with image crash, which i tried to debug and was crashing in eeAllocateXYZ routines (cant remember the name, but those which allocating new objects without triggering GC)? When i built VM for debugging that time, it also had this "mouse cursor blinking" behavior.. but before i paid no attention to error console window (it doesn't scrolls , so if you don't scroll it, you don't see error messages). Now i know why, because it was screaming into console with a lot of assertion messages failed. So , i suspect that this regression was introduced a while ago, but was unnoticed before now.
-- best, Eliot