ERROR: found a frozen edge #234984 (not packed) in the root cell!

I’m getting the following error from ace, for a rather long sentence in a grammar with lots of ambiguity.

out of sync; arbiter sent ‘ERROR: found a frozen edge #234984 (not packed) in the root cell!’ when expecting a SENT or SKIP header.
failed to read result for 4280

Is that more or less a memory error (I get it even after requesting 100GB of memory on Condor) or is something else going on?

It could be related to running out of memory, but 100GB is a lot. It could be an ACE bug. If you parse on the terminal instead of through art, you should see how much RAM was used for that input, which should help answer that question. What ACE command line options did you use?

It is a lot! And the log shows that it used 102GB before it crashed.

I just used the -g option

When I parse through the terminal… this will take a while. And it won’t show me how much RAM until the end, right?

It is repeatedly printing this warning for each edge though

WARNING: grammar rule `basic-head-opt-comp’ is loopy
WARNING: edge #188075 [basic-head-opt-comp] == edge #188065 [basic-head-opt-comp]

Okay, it did finally parse in the terminal:
NOTE: 1 readings, added 129432 / 129296 edges to chart (60995 fully instantiated, 105 actives used, 28254 passives used) RAM: 1445833k

So does that mean I was hitting a memory error? Is there a different option I should use to get this to parse from art?

head-opt-comp being loopy suggests that something might have an underspecified COMPS list … do you perhaps have argument composition auxiliaries in this language?

Yes? I have auxiliaries that take a V complement.

That looks like a matrix bug: V-complement auxiliaries + head-opt-comp leads to endless chains of head-opt-comp. I’m actually surprised that ace manages to terminate here…

I think the quickest fix for this in a grammar or in customization is to make head-opt-comp rule say [ AUX - ] on the head daughter.

Do I have this right? I added this to hix.tdl:

basic-head-opt-comp-phrase :+ [ HEAD-DTR.SYNSEM.LOCAL.CAT.HEAD.AUX - ].

And then recompiled the grammar. But I still get the loopy rule warning.

That looks right to me. Can you confirm that the auxiliaries are [ AUX + ]?

If I read that right, the terminal invocation of ACE used just 1.4GB. That is the default limit. If you want ace to use more you have to tell it to, with —max-chart-megabytes=99000 and —max-unpack-megabytes=100000, or something similar.

If you weren’t including those in the -a part of your art invocation then I am surprised that you reached 102GB somehow. What log said that?

The fact that there are loopy rules might indeed be what is leading to the surprising frozen edge still in the chart at unpack time. These are expected to be packed into edged that theoretically must be found further down the search, but when loops are present ACE cuts the search to prevent infinite time and memory usage. I’m not sure there’s much to do about that, but it does look like there’s a formatting issue with that error message that lead to art not processing the item correctly, so that at least goes on the todo list!

Woodley

They are and verbs are AUX -

Where does —max-chart-megabytes=99000 —max-unpack-megabytes=100000 go in my command? I tried a couple places and get errors.

Sorry- I think I’m wrong about the 102GB. That was in my condor log as “requested” and “allocated”, but I guess that doesn’t mean used.

Can you test a very short sentence with that grammar to see what’s going on interactively?

The problem might be that my email program converts double hyphens into m-dashes. Those options go anywhere on the ace command line (other than between the -g and the grammar path). With art I assume you are using -a “ace …”. The parameters go inside the quotes there, as they are part of the ace invocation.

@ebender Can you tell me a little more about what I should be looking for. I can parse short sentences with this grammar, including sentences with and without auxiliaries. The problematic sentence is particularly long and I think has multiple auxiliaries, but sub-parts of that sentence parse. There’s not problematic word or phrase that I can identify.

Thanks! Doing that resolved the problem!

These are hard to debug, I’m afraid. If the individual parts of the sentence don’t send the rule into loops, then maybe it’s something about how the auxiliaries combine? Any chance that they are getting coordinated, and resulting in a feature structure that’s underspecified for COMPS and AUX?