[Rd] R 4.0.1-4.0.5 built with Intel Composer 19.0-19.1.1, error in "make check" on CentOS 7.7-7.9

[Ryan Novosielski]

> On Apr 16, 2021, at 12:12 PM, Ivan Krylov <krylov.r00t using gmail.com> wrote:
> 
> On Thu, 15 Apr 2021 22:46:56 +0000
> Ryan Novosielski <novosirj using rutgers.edu> wrote:
> 
>> (gdb) print $_siginfo._sifields._sigfault
>> $1 = {
>> si_addr = 0x7fffff7fecf8, _addr_lsb = 0,
>> _addr_bnd = {_lower = 0xffff9215f829ff58, _upper = 0x7fffff7fecf8}
>> }
> 
>> (gdb) print R_CStackDir * (R_CStackStart - (uintptr_t)&codebase)
>> $5 = 18446744073701307232
> 
> Okay, this is clearly a stack overflow: the faulting address is close
> to addresses of other stack variables, and the stack usage, calculated
> manually as 140737488207872 - 0x7fffff7ff360, is 8244392, which is
> above the (7969177), but the value that gdb gives you looks really
> strange. I could only get that value when I calculated
> -1 * (140737488207872 - 0x7fffff7ff360) and reinterpreted it as
> unsigned.
> 
> What is the value of R_CStackDir at the moment of crash? Could it have
> somehow became -1 despite the stack growing down?

Well it definitely somehow could have, since it did:

Program received signal SIGSEGV, Segmentation fault.
bcEval.R (body=0x3eb7748, rho=0x3f72770, useCache=TRUE) at /scratch/novosirj/install-files/R-4.0.5/src/main/eval.c:6478
6478      codebase = pc = BCCODE(body);

(gdb) print R_CStackDir
$1 = -1

--
#BlackLivesMatter
____
|| \\UTGERS,  	 |---------------------------*O*---------------------------
||_// the State	 |         Ryan Novosielski - novosirj using rutgers.edu
|| \\ University | Sr. Technologist - 973/972.0922 (2x0922) ~*~ RBHS Campus
||  \\    of NJ	 | Office of Advanced Research Computing - MSB C630, Newark
     `'