The file is 47MB long

looking at the details, everything is what I expected

No - there were no

MAGIC

settings for

user_proj_example

either. But it does have over 30 thousand standard cells in it

To continue the results of my investigation: I copied (with slight fixes) the example lefreader program given in the appendix of the user manual for lefdef in the coriolis library and so was able to call lefyyparse() on my file and it worked just fine. I noticed some magic numbers at the start of

lef.y

have been increased over the years so I tried setting them back to the original values in the extremely unlikely case OpenTriton has been compiled against a really old version of the coriolis library (before 2008). The resulting program also read my lef file ok. The program in the appendix uses callbacks that just print things while OpenTriton's callbacks do different things. So lefyyparse() calls code given to it and that code might be getting into the infinite loop

I was able to run OpenTriton in gdb and verified that

LefDefParser::lefyyparse()

calls

fr::io::Parser::Callbacks::getLefPins(LefDefParser::lefrCallbackType_e, LefDefParser::lefiPin*, void*)

which in turn calls standard library stuff but does not itself every return.

I thought it might be in a infinite loop, but now I am not sure. I more carefully looked at the

merged_unpadded.lef

in both

user_proj_example

(45MB but OpenTriton likes it) and

user_project_wrapper

(47MB and which OpenTriton is choking on) and found a significant difference: the latter has definitions for

PIN VPWR

and

PIN VGDN

which are nearly half a million lines long! Many, many rectangles to nwell and pwell respectively besides other layers

Previously I had lots of problems with the tools generating fillers and well taps throughout the whole wrapper. Hmmm... I fixed that, but it might be a good idea to not leave any files around from previous runs....

No, clearing all files from previous runs did not help. I will leave OpenTriton running for at least 8 hours since perhaps that is the time it needs to go from an 8 line PIN definition to a 400,000 line one

mergelef.py

is run twice to create the file