Pattern match operator with alternation core dumps with input string as small as 16K
Final Release Note
Description
This is an issue I noticed while trying to investigate MAX_STRLEN issues with $query. This one is with the pattern match operator & alternation usage.
> ver v63001a d
> gtm
GTM>for i=1:1:20 s x=$j(1,2**i) w "$zlength(x)=",$zlength(x)," : x?.(1""1"",1"" "") = ",x?.(1"1",1" "),!
$zlength(x)=2 : x?.(1"1",1" ") = 1
$zlength(x)=4 : x?.(1"1",1" ") = 1
$zlength(x)=8 : x?.(1"1",1" ") = 1
$zlength(x)=16 : x?.(1"1",1" ") = 1
$zlength(x)=32 : x?.(1"1",1" ") = 1
$zlength(x)=64 : x?.(1"1",1" ") = 1
$zlength(x)=128 : x?.(1"1",1" ") = 1
$zlength(x)=256 : x?.(1"1",1" ") = 1
$zlength(x)=512 : x?.(1"1",1" ") = 1
$zlength(x)=1024 : x?.(1"1",1" ") = 1
$zlength(x)=2048 : x?.(1"1",1" ") = 1
$zlength(x)=4096 : x?.(1"1",1" ") = 1
$zlength(x)=8192 : x?.(1"1",1" ") = 1
$zlength(x)=16384 : x?.(1"1",1" ") = Segmentation fault (core dumped)
With pro, the failure still happens around the 16K mark but I do not get any output at all like dbg. I only get the core dumped message.
The core stack trace shows ~ 32K C-frames. So it is possibly a C-stack overflow.
Core was generated by `/usr/library/V63001A/dbg/mumps -direct'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007fde9e4ce68e in do_patalt (firstalt=0x231df4a, strptr=0x232dab3 ' ' <repeats 200 times>...,
strtop=<error reading variable: Cannot access memory at address 0x7ffdc9913ff8>,
repmin=<error reading variable: Cannot access memory at address 0x7ffdc9913ff4>,
repmax=<error reading variable: Cannot access memory at address 0x7ffdc9913ff0>,
totchar=<error reading variable: Cannot access memory at address 0x7ffdc9913fec>, repcnt=30785, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:162
162 {
(gdb) where
#0 0x00007fde9e4ce68e in do_patalt (firstalt=0x231df4a, strptr=0x232dab3 ' ' <repeats 200 times>...,
strtop=<error reading variable: Cannot access memory at address 0x7ffdc9913ff8>,
repmin=<error reading variable: Cannot access memory at address 0x7ffdc9913ff4>,
repmax=<error reading variable: Cannot access memory at address 0x7ffdc9913ff0>,
totchar=<error reading variable: Cannot access memory at address 0x7ffdc9913fec>, repcnt=30785, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:162
#1 0x00007fde9e4cf135 in do_patalt (firstalt=0x231df4a, strptr=0x232dab2 ' ' <repeats 200 times>...,
strtop=0x232e273 "32768", repmin=0, repmax=1048576, totchar=1985, repcnt=30784, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:311
.
.
#30782 0x00007fde9e4cf135 in do_patalt (firstalt=0x231df4a, strptr=0x2326275 ' ' <repeats 200 times>...,
strtop=0x232e273 "32768", repmin=0, repmax=1048576, totchar=32766, repcnt=3, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:311
#30783 0x00007fde9e4cf135 in do_patalt (firstalt=0x231df4a, strptr=0x2326274 ' ' <repeats 200 times>...,
strtop=0x232e273 "32768", repmin=0, repmax=1048576, totchar=32767, repcnt=2, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:311
#30784 0x00007fde9e4cf135 in do_patalt (firstalt=0x231df4a, strptr=0x2326273 ' ' <repeats 200 times>...,
strtop=0x232e273 "32768", repmin=0, repmax=1048576, totchar=32768, repcnt=1, min_incr=0, max_incr=1)
at /Distrib/GT.M/V63001A/sr_port/do_patalt.c:311
#30785 0x00007fde9e16b687 in do_pattern (str=0x22d0da0, pat=0x7fde9f11d520)
at /Distrib/GT.M/V63001A/sr_port/do_pattern.c:183
#30786 0x00007fde9dff86ff in l1 () at /Distrib/GT.M/V63001A/sr_x86_64/op_pattern.s:40
#30787 0x000000000231dbe8 in ?? ()
#30788 0x00007fde9f11d6ea in ?? ()
#30789 0x00007fde9e5ce218 in ?? () from /usr/library/V63001A/dbg/libgtmshr.so
#30790 0x00007ffdca111170 in ?? ()
#30791 0x0000000000000000 in ?? ()
Not sure exactly what the issue is here. Needs more investigation.
I think this is not normal in practice (i.e. examining a 16K length string for pattern matches with alternation specified in the pattern). But nevertheless there is now an issue to track this.
Draft Release Note
Edited by Narayanan Iyer