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/../trigger.mtr'
loading maxent model 0 ms
reading tree labels from `ace/../labels.tdl'
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.
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 sweaglesw.org/linguistics/acetools/).
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?