Re: assertion failed in luajit

  • From: Laurent Deniau <Laurent.Deniau@xxxxxxx>
  • To: "luajit@xxxxxxxxxxxxx" <luajit@xxxxxxxxxxxxx>
  • Date: Fri, 7 Oct 2016 06:06:44 +0000

On 07 Oct 2016, at 03:55, Demi Obenour <demiobenour@xxxxxxxxx> wrote:

So the token was getting garbage collected?

Yes. When leaving the current FuncState, its key table is removed from the 
stack and everything becomes collectable i.e. the global variable name of the 
current assignment was collected. I missed this point when I wrote the lambda 
syntax extension because I never use global variables, so I even didn’t thought 
about this corner case in the extended grammar.
Do you have an open source version of your lambda patch?

My patch contains all my extensions. If you are only interested by lambda 
syntax, look for LUAJIT_LAMBDA_SYNTAX guards in the lexer and the parser:

https://github.com/MethodicalAcceleratorDesign/LuaJIT/blob/mad-patch/src/lj_lex.h
http://github.com/MethodicalAcceleratorDesign/LuaJIT/blob/mad-patch/src/lj_lex.c
http://github.com/MethodicalAcceleratorDesign/LuaJIT/blob/mad-patch/src/lj_parse.c

I can provide a patch with only the lambda syntax extension on demand (I would 
also recommend the local in table extension as it is pretty useful and should 
be part of Lua itself).

(If you want to see why I needed lambda syntax (compact form), you can look at 
the file:
https://github.com/MethodicalAcceleratorDesign/MAD/blob/master/tests/share/lhc_as-built.mad
It contains about 30000 lambda functions, manipulated by studies in other files 
that load it. LuaJIT digests this lattice definition about 4x faster than our 
dedicated tool and consumes about 20x less memory while providing much more 
features.)

Best,
Laurent.

On Oct 6, 2016 3:39 PM, "Laurent Deniau" <Laurent.Deniau@xxxxxxx 
<mailto:Laurent.Deniau@xxxxxxx>> wrote:
Hi,

On 05 Oct 2016, at 21:18, Peter Cawley <corsix@xxxxxxxxxx 
<mailto:corsix@xxxxxxxxxx>> wrote:

On Wed, Oct 5, 2016 at 5:31 PM, Laurent Deniau <Laurent.Deniau@xxxxxxx 
<mailto:Laurent.Deniau@xxxxxxx>> wrote:
Since I see no difference in the byte code emitted with and without lambda 
notation, I cannot figure out if it is related to it or not…

So, to confirm:
1. You've modified the LuaJIT parser to parse new syntax.

Yes, but it relies heavily on the existing code to minimise support when the 
original code changes. Moreover, I have 10000 lines full of lambda syntax and 
extensive unit tests, but this is the first time that I had to use global 
variables with compact form of the lambda syntax, combined with large code 
base to stress the GC to do many steps in the right place, i.e. the only case 
where the problem occurs...

2. Your modified parser, when parsing your new syntax, is hitting an
assertion failure.

Right.

If so, I would posit that your modifications to the parser contain a
bug.

Right, this is also the conclusion of my posts, it is related to the GC _and_ 
the lambda syntax (compact form only).

If you can point us toward your modifications, then perhaps we'll
be able to point out your mistake (though my interest in the issue has
significantly declined given the presence of these modifications).

Fair enough. I was not asking to debug my modifications, but more to see if 
my case/explanation would ring a bell to some expert.

So I found the bug and corrected it. It is effectively related to the GC and 
the lambda syntax, which opened a pandora box in the Lua grammar, hence 
LuaJIT itself is _not_ concerned.

(To make it short, the token lookahead made to close expr and terminate the 
lambda function was not anchored in the right FuncState table. This case does 
not exist in the Lua grammar because all lookahead are in the current 
FuncState. So I solved the problem by writing a small function to anchor the 
last TK_name read after the lambda function expr (if any) in the previous 
FuncState.)

Many thanks for you time.

Best,
Laurent.

--
Laurent Deniau                           http://cern.ch/mad ;
<http://cern.ch/mad>
Accelerators Beam Physics        mad@xxxxxxx <mailto:mad@xxxxxxx>
CERN, CH-1211 Geneva 23       Tel: +41 (0) 22 767 4647 
<tel:%2B41%20%280%29%2022%20767%204647>


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts: