Very nice follow-up, Simon.
On 19 December 2022 at 13:57, Simon Urbanek wrote:
| 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@entry=0x625000706ba0,
op=op@entry=0x62500000b678, args=<optimized out>, env=0x1, env@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?
Yep. And as I had on schedule for some time with no issues it likely is
external. No obvious how to minimize it to a smaller reproducible example
though.
Best, Dirk
| Cheers,
| Simon
|
|
| > On 19/12/2022, at 8:41 AM, Dirk Eddelbuettel <e...@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 | e...@debian.org
| >
| > ______________________________________________
| > R-devel@r-project.org mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
|
--
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
