Ace segfaults building rule filter

Question for @sweaglesw (or anyone else who might know): What likely cause of a segfault at this point?

simple lexemes              0 / 994 = 0.00%
2222 types (743 glb), 994 lexemes, 148 rules, 95 orules, 39 instances, 1474 strings, 156 features
reading trigger-rule        from `ace/../'
loading maxent model        0 ms
reading tree labels         from `ace/../labels.tdl'
loading tree-node-labels
rule filter...              Segmentation fault

I believe I saw some segfaults related perhaps to too much morphology (maybe ACE was running out of allocated memory at some point?) But I am not sure.

I can’t quite guess from the log, unfortunately. I’m not sure I’ve seen a crash at that location. Obviously a bug of some sort in ACE; I’d be happy to look if you can provide the grammar in question.

Thanks, Woodley. I’ll email the grammar.

This turned out to be a simple but long standing and until now-latent bug in the way memory was managed during rule filter creation. Mea culpa, and thanks for the report. I’ve checked one-liner the fix into SVN and can provide a new binary release sometime tomorrow, but I need to head to bed now instead of running regression tests and release scripts :-).


Please try the new ACE 0.9.31, which fixes this bug.

1 Like

Hi @sweaglesw, what about the other tools depending on ACE? New binaries are needed?

Actually, did you have a chance to commit in the repo the change on the listening port of FFTB?

I posted a new copy of the “acetools” package at the same time as the new ACE binaries (see

I did not change the FFTB listening address; my impression was using SSH port forwarding was generally a good solution without exposing the system to arbitrary marauding web agents. If it’s important to you to have FFTB listen on public IP addresses, maybe I should add a command line option for that?