Segmentation fault in Lstrcpy() under INTERPRET

[RossPatterson]

This was discoved in CMS370, but fails in the original bREXX the same way.

The instruction Interpret 'Return F()' crashes bREXX with a segmentation fault. This has been verified in bREXX 2.1.9.

Test case:

/* */
Interpret 'Return F()'
Exit

F: Procedure
Return 2

This happens because something I haven't yet located in bREXX is calling Lstrcpy() with a to parameter set to 0. The segfault occurs when Lstrcpy() attempts to store into the Lstr object at that location.

There is a work-around: store the function result into a variable, and return that instead. This example works fine:

Interpret 'R = F()'
Return R

F: Procedure
Return 2

[RossPatterson]

Digging into the core dump with GDB, the backtrace is:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000564716ac781c in Lstrcpy (to=0x0, from=0x564716ad8e20 <_tmpstr+32>) at lstring.c:252
252             if ( LISNULL(*to) ) {
(gdb) bt
#0  0x0000564716ac781c in Lstrcpy (to=0x0, from=0x564716ad8e20 <_tmpstr+32>) at lstring.c:252
#1  0x0000564716ab0476 in RxInterpret () at interpre.c:1402
#2  0x0000564716aa65b4 in RxRun (filename=0x0, programstr=0x7ffed01d75f0, arguments=0x7ffed01d7630, tracestr=0x7ffed01d7610, environment=0x0) at rexx.c:489
#3  0x0000564716aa50fe in main (ac=2, av=0x7ffed01d7928) at main.c:228

Moving up to Lstrcpy()'s caller, we see:

(gdb) up
#1  0x0000564716ab0476 in RxInterpret () at interpre.c:1402
1402                                    Lstrcpy(_proc[_rx_proc].arg.r, STACKTOP);
(gdb) print _rx_proc
$1 = 1
(gdb) print _proc[1]
$2 = {id = 1, calltype = 3, ip = 40, stack = 18446744073709551615, stacktop = 0, scope = 0x5647174b2b58, arg = {n = 0, r = 0x0, a = {
      0x0 <repeats 15 times>}}, env = 0x5647174b2c38, digits = 30, fuzz = 0, form = 0, condition = 0, lbl_error = 0x56471747cc28,
  lbl_halt = 0x56471747c7f8, lbl_novalue = 0x56471747cfa8, lbl_notready = 0x56471747d168, lbl_syntax = 0x56471747d608, codelen = 176, codelenafter = 272,
  clauselen = 4, trace = 32, interactive_trace = 0}

calltype = 3 is CT_INTERPRET, which makes sense, we're in the OP_RETURNF implementation running under an INTERPRET instruction. And there's the zero, right in arg.r: arg = {n = 0, r = 0x0, ....

I'm not sure where to go from here :-(