Show quoted text> I don't know of a public debugging interface, but is there any way you
> could step through Regexp::Grammars' matching to see what triggers the
> segfault?
As Yves subsequently suggested, it's likely this issue is down in guts of
Perl
and not a response to any particular component of Regexp::Grammars. So
stepping through the grammar parse is unlikely to help determine the
problem. Unless someone stepped through it with gdb or some other
interpreter-level debugger.
Show quoted text> Even if it's inherent in how the program is written, memory shouldn't
> be a problem, as my computer (& address space) have far more than 2GB
> of memory.
Agreed. As does mine. But, again as Yves suggested, something is hitting
the 32-bit limit even if it's not malloc.
Show quoted text> I can't use separators in most cases, because I have multiple
> separators of equal precedence that I need to preserve. For example,
> <[factor]> % [-+] doesn't preserve whether the tail factors were added
> or subtracted, and I don't see anything in the documentation on how to
> preserve them.
You can remove the recursion by named-capturing the separators as well (as
a list):
<[factor]>+ % <[operator=([-+])]>
But, yes, this will only defer the problem, not prevent it.
It will cause fewer subrule calls, but eventually the 2GB
limit will still be reached and the segfault will occur.
Damian