leepro / unladen-swallow

Automatically exported from code.google.com/p/unladen-swallow
Other
0 stars 0 forks source link

Ghost fatal guard failure in simple function #111

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
The attached script generates a fatal guard failure when run with
instrumentation, but does not obey the bail as error setting.

Code objects that failed fatal guards:
    file:line (funcname) bail hotness -> final hotness
    y:13 (y)    100010 -> 500010

Forcing another bail gives:

Bailed to the interpreter 1 times
TRACE_ON_ENTRY: 0
LINE_TRACE: 0
BACKEDGE_TRACE:0
CALL_PROFILE: 0
FATAL_GUARD_FAIL: 0
GUARD_FAIL: 1

Original issue reported on code.google.com by joerg...@gmail.com on 10 Jan 2010 at 2:50

Attachments:

GoogleCodeExporter commented 8 years ago
I'm pretty sure the fatal bail is caused by the assignment of i in the global 
scope
during the for loop.  When that happens, we invalidate the machine code 
associated
with y since it will cache a pointer to obj in the IR, and if the globals dict 
gets
modified, we can't rely on that assumption anymore.

There is no RuntimeError because we invalidate the machine code before it starts
running, ie when i is reassigned in the for loop, but a fatal bail is recorded 
anyway.

Maybe "fatal bail" is not the right way to describe this occurrence in the
instrumentation.  "Invalidated machine code" seems more accurate to me.

Original comment by reid.kle...@gmail.com on 10 Jan 2010 at 9:09

GoogleCodeExporter commented 8 years ago
Moving the loop into a function 'fixes' the problem. I vote for a renaming!

Original comment by joerg...@gmail.com on 10 Jan 2010 at 10:06

GoogleCodeExporter commented 8 years ago
We could also raise RuntimeError at the place the dict modification happens. 
That would 
make it a lot easier to track down *why* your machine code is being invalidated.

Original comment by collinw on 11 Jan 2010 at 4:37