Grammar loads but goes into some infinite(?) loop at parsing

I have a grammar which I obtained from the Matrix which loads but then breaks at parsing (any sentence, so far as I can tell).

In the LKB, it seems to be silently spinning (regardless of the maximum number of edges that I set in the options).

In ACE, I get the error:

Assertion failed: (copypathp < MAX_COPY_PATH), function copy_dg_with_comp_arcs_ss, file unify.c, line 445.
Abort trap: 6 

From just looking at the phrase structure rules, I am not immediately spotting the reason (but then I don’t really know what to look for).

@sweaglesw, do you know if the error above usually means a particular type of problem in the grammar?

If not, does anyone have any idea what I should be looking for?

It is a V-initial language, which I believe is a somewhat less tested area in the customization system…

What’s also interesting is, when I accidentally entered a sentence with an OOV word, ACE complained about it but the LKB didn’t.

Silently spinning = it doesn’t say something about max edges being reached? If so, this is typical of something spinning in the morphology.

1 Like

The error means an AVM was encountered whose depth (longest path of features to get to something) exceeded 1024, an arbitrary limit ACE used to flag that something unintended is probably happening. I recommend parsing with -vvv, which will dump the feature structures to the terminal as it goes. Redirecting to a log file is a good idea, as you will get a LOT of output. Towards the bottom you will almost certainly find some phenomenally huge AVMs with a repeating chain of substructures. This means some rule is spinning. The log will tell you which rule produced the AVM right before it prints it. Situations like this sometimes involve two or more rules alternating with each other, so you might need to look back and try to find the pattern of rule applications. You will have to keep track of edge numbers in the log to do that. It will almost certainly be one or more unary rules — possibly, as Emily suggested, a lexical/orthographemic rule, but I wouldn’t guarantee it.

1 Like

In the LKB, the best way to debug this is to turn off packing

(setq *chart-packing-p* nil)

and reduce the edge limit, e.g.

(setq *maximum-number-of-edges* 200)

so the parser stops itself quickly. Otherwise it could get into a cycle of building and copying ever larger feature structures and getting slower and slower, never reaching the edge limit; this can happen with the new append list mechanism.

Once the parser has run into the edge limit, view the chart. In the graphical view, you might see a long horizontal line of rule applications. If so, this shows you the group of unary rules that are applying to each other circularly. Alternatively, print the chart to the terminal window, by


and look for repeated lines.

@olzama, if this doesn’t do the trick, please email me your grammar and I’ll investigate and come up with an alternative debugging strategy.

1 Like

@johnca, I know I’ve asked this before but for the life of me I can’t locate the answer. (Hopefully, having the answer here will help in the future.) In LKB-FOS, how do I get access to the terminal? I’ve seen it open a couple times, actually, but most of the time it doesn’t, and I only have the GUI.

Regardless of my question about how to get the terminal in LKB-FOS, the strategy worked for me (in classic LKB) and I was able to see which rule is cyclic. Thank you!

@olzama, you don’t get access to a terminal if you start the LKB by double-clicking To get a terminal, create an xterm from XQuartz or run, and then start the LKB by typing the name of the unix binary on the command line; you can then run Lisp expressions from that terminal.

Co-incidentally, I’m in the process of adding to LKB-FOS a new menu command “Evaluate lisp expression…”, which will come preloaded with a few common commands to make this easier.

1 Like