[Rd] Repeated segfault at installing sysdata.rda with clang/san build

[Simon Urbanek]

This crashes unceremoniously in glibc:

> tools:::sysdata2LazyLoadDB("./R/sysdata.rda","../../../library/tools/R")
xdrmem_create(0x7ffdf19699e0, 0x7ffdf1969ba0, 4)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt

#0  0x0000000000000000 in ?? ()
#1  0x00005559317e61d4 in xdrmem_create ()
#2  0x00007fd82b9bd08b in R_XDRDecodeInteger (buf=<optimized out>) at saveload.c:2246
#3  0x00007fd82ba007db in InInteger (stream=0x7ffc57b50f40) at serialize.c:425
#4  0x00007fd82b9ff743 in R_Unserialize (stream=0x7ffc57b50f40) at serialize.c:2175
#5  0x00007fd82ba0bfa4 in do_unserializeFromConn (call=0x625000706cb8, op=0x6250000298a8, args=<optimized out>, env=<optimized out>) at ser\
ialize.c:2628
#6  0x00007fd82b8b5435 in do_internal (call=call using entry=0x625000706ba0, op=op using entry=0x62500000b678, args=<optimized out>, env=0x1, env using entry\
=0x625000d7b3a0) at names.c:1403

int attribute_hidden R_XDRDecodeInteger(void *buf)
{
    XDR xdrs;
    int i, success;

    xdrmem_create(&xdrs, (char *) buf, R_XDR_INTEGER_SIZE, XDR_DECODE);

The odd thing is there is nothing wrong with the input, the location is accessible and just 4 bytes of an integer as expected:

(gdb) p/x *((int*)0x7ffdf1969ba0)
$4 = 0x3000000

which should turn into a perfectly normal 3L, so this a something bad happening in xdrmem_create() which is part of glibc. But looking at glibc sources, nothing suspicious in there, since it just populates XDR and shouldn't call any function, but yet it looks like it is trying to call a function which is a NULL pointer ... This is outside of R so really odd - perhaps some odd interaction of *SAN and glibc? No idea why it suddenly appeared - perhaps some changes in toolchain or glibc?

Cheers,
Simon


> On 19/12/2022, at 8:41 AM, Dirk Eddelbuettel <edd using debian.org> wrote:
> 
> 
> I have maintained two SAN/UBSAN builds (one gcc, one clang) for many years
> (even though I also happily use Winston's newer/bigger container and
> generally recommend its use) and still have GitHub actions build them on a
> weekly schedule (as they follow r-devel).
> 
> The clang one started to fail a little while ago. I just tried it locally,
> and it too blew up in the same spot:
> 
> 
> [...]
> make[4]: Entering directory '/tmp/R-devel/src/library/tools'
> installing 'sysdata.rda'
> 
> *** caught segfault ***
> address (nil), cause 'memory not mapped'
> 
> Traceback:
> 1: load(srcFile, e)
> 2: tools:::sysdata2LazyLoadDB("./R/sysdata.rda", "../../../library/tools/R")
> An irrecoverable exception occurred. R is aborting now ...
> /bin/bash: line 2: 10795 Done                    echo "tools:::sysdata2LazyLoadDB(\"./R/sysdata.rda\",\"../../../library/tools/R\")"
>     10796 Segmentation fault      (core dumped) | R_DEFAULT_PACKAGES=NULL LC_ALL=C R_ENABLE_JIT=0 TZ=UTC ../../../bin/R --vanilla --no-echo
> make[4]: Leaving directory '/tmp/R-devel/src/library/tools'
> make[4]: *** [../../../share/make/basepkg.mk:151: sysdata] Error 139
> make[3]: *** [Makefile:36: all] Error 2
> make[3]: Leaving directory '/tmp/R-devel/src/library/tools'
> make[2]: Leaving directory '/tmp/R-devel/src/library'
> make[2]: *** [Makefile:37: R] Error 1
> make[1]: *** [Makefile:28: R] Error 1
> make[1]: Leaving directory '/tmp/R-devel/src'
> make: *** [Makefile:61: R] Error 1
> 
> 
> I assume it shouldn't. But I am also not too familiar with internals of
> sysdata and the lazyload format.  The Dockerfile is in the repository at
> 
>  https://github.com/rocker-org/r-devel-san-clang
> 
> in case someone else wants to take stab. I may try this on my Ubuntu machine
> too in temporary directory.
> 
> Dirk
> 
> -- 
> dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org
> 
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>