Re: stack overflow in patmatch()

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, May 10, 2025 at 9:41 PM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>
> Long story short, [1] has this line of code:
> [[ "$proc_buf" = (#b)(#s)(([[:space:]]|\\$'\n')#) ]]
>
> which causes this backtrace (parts elided)
> (gdb) bt
> #0  0x000000000049d098 in patmatch (
>     prog=<error reading variable: Cannot access memory at address
> 0x7fffff7fef38>)
>     at pattern.c:2695
> #1  0x000000000049e673 in patmatch (prog=0x5073d0) at pattern.c:3252
> #2  0x000000000049dd8e in patmatch (prog=0x507398) at pattern.c:2978
> ...
> #8182 0x000000000049dcdc in patmatch (prog=0x507358) at pattern.c:2952
> #8183 0x000000000049ca21 in pattryrefs (prog=0x507320,

Stack overflow is difficult to handle.  There's no good way to predict
that it's about to happen and no way to recover once it does happen.
The only option is to put a limit on recursion depth (like we do for
math functions), which causes incorrect results on some inputs and has
to be a conservative number to have a high probability of preventing
overflow.

> What are the thoughts here, is this an error in the z-sy-h script's
> pattern, or could we improve patmatch() to at least not crash?

I don't think it's possible to implement (...)# in O(1) space,
especially with backreferences, so replacing recursion with a loop
will just postpone the crash until memory is exhausted.  Which
admittedly would be unlikely in this example.

PWS most recently worked on patmatch(), I think.