Re: lib/56239 (lib/libc/regex/t_exhaust:regcomp_too_big test fails)

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

The following reply was made to PR lib/56239; it has been noted by GNATS.

From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: christos%NetBSD.org@localhost
Subject: Re: lib/56239 (lib/libc/regex/t_exhaust:regcomp_too_big test fails)
Date: Sun, 05 Jun 2022 18:59:05 -0400

 I have found that regcomp_too_big also fails for me on an HPPA machine,
 using HEAD/202206030100Z sources.  The symptoms are a bit different:
 
 tc-start: 1654467008.118185, regcomp_too_big
 tc-se:Test program crashed; attempting to get stack trace
 tc-se:[New process 11163]
 tc-se:Core was generated by `t_exhaust'.
 tc-se:Program terminated with signal SIGSEGV, Segmentation fault.
 tc-se:#0  0xaf85bea4 in wgetnext (p=3D0xb0001e88) at /home/tgl/netbsd-H-20=
 2206030\
 100Z/usr/src/lib/libc/regex/regcomp.c:1658
 tc-se:#0  0xaf85bea4 in wgetnext (p=3D0xb0001e88) at /home/tgl/netbsd-H-20=
 2206030\
 100Z/usr/src/lib/libc/regex/regcomp.c:1658
 tc-se:#1  0xaf85f19c in p_ere_exp (p=3D0xb0001e88, bc=3D<optimized out>) a=
 t /home/t\
 gl/netbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:527
 tc-se:#2  0xaf85ccf8 in p_re (p=3D0xb0001e88, end1=3D41, end2=3D-130) at /=
 home/tgl/ne\
 tbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:853
 tc-se:#3  0xaf85f06c in p_ere_exp (p=3D0xb0001e88, bc=3D<optimized out>) a=
 t /home/t\
 gl/netbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:476
 tc-se:#4  0xaf85ccf8 in p_re (p=3D0xb0001e88, end1=3D41, end2=3D-130) at /=
 home/tgl/ne\
 tbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:853
 tc-se:#5  0xaf85f06c in p_ere_exp (p=3D0xb0001e88, bc=3D<optimized out>) a=
 t /home/t\
 gl/netbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:476
 tc-se:#6  0xaf85ccf8 in p_re (p=3D0xb0001e88, end1=3D41, end2=3D-130) at /=
 home/tgl/ne\
 tbsd-H-202206030100Z/usr/src/lib/libc/regex/regcomp.c:853
 ...
 
 It looks like an infinite recursion, but it turns out not to be:
 if I increase the ulimit -s setting from the platform's default 2048
 to 4096, the test passes!
 
 This may or may not be directly related to the issue seen on aarch64.
 It'd be interesting to check if messing with "ulimit -s" changes the
 behavior on other platforms.
 
 			regards, tom lane