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.
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)..
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.
On Fri, Sep 28, 2012 at 5:55 PM, 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.
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)..
I am copy pasting from an old thread. Notice the yellow part:
*(gdb) break warning Breakpoint 1 at 0x105e2b: file /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c, line 39. (gdb) run -breaksel initialize ~/Squeak/Squeak4.2/trunk4.2.image Starting program: /Users/eliot/Cog/oscogvm/macbuild/Debug.app/Contents/MacOS/Croquet -breaksel initialize ~/Squeak/Squeak4.2/trunk4.2.image Reading symbols for shared libraries .+++++++++++++++..................................................................................... done Reading symbols for shared libraries . done
Breakpoint 1, warning (s=0x16487c "send breakpoint (heartbeat suppressed)") at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:39 39 printf("\n%s\n", s); (gdb) where 5 #0 warning (s=0x16487c "send breakpoint (heartbeat suppressed)") at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:39 #1 0x0010b490 in interpret () at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:4747 #2 0x0011d521 in enterSmalltalkExecutiveImplementation () at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:14103 #3 0x00124bc7 in initStackPagesAndInterpret () at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:17731 #4 0x00105ec9 in interpret () at /Users/eliot/Cog/oscogvm/macbuild/../src/vm/gcc3x-cointerp.c:1933 (More stack frames follow...)*
So that will halt whenever #intiialize is sent. However, if you do not put that, I THINK that the assert also calls warning() so it should also halt.
Here is what I understood when Eliot told me about that:
*So, if I understood correctly, I can put a breakpoint in the function warning() with "break warning". With the -breaksel parameter you set an instVar with the selector name and size. Then after, anywhere I can send #compilationBreak: selectorOop point: selectorLength and that will magically check whether the selectorOop is the one I passes with -breaksel and if true, it will call warning, who has a breakpoint, hence, I can debug :) AWESOME!!!! Now with CMake I can even generate a xcode project and debug it :) (I don't know why attaching gdb from Xcode crash the vm). *
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.
-- Best regards, Igor Stasenko.
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).
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.
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.
Igor Stasenko.
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
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Igor Stasenko -
Mariano Martinez Peck