[Rd] Repeated segfault at installing sysdata.rda with clang/san build
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 Doneecho
"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
Re: [Rd] Repeated segfault at installing sysdata.rda with clang/san build
This crashes unceremoniously in glibc:
> tools:::sysdata2LazyLoadDB("./R/sysdata.rda","../../../library/tools/R")
xdrmem_create(0x7ffdf19699e0, 0x7ffdf1969ba0, 4)
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0 0x in ?? ()
#1 0x5559317e61d4 in xdrmem_create ()
#2 0x7fd82b9bd08b in R_XDRDecodeInteger (buf=) at
saveload.c:2246
#3 0x7fd82ba007db in InInteger (stream=0x7ffc57b50f40) at serialize.c:425
#4 0x7fd82b9ff743 in R_Unserialize (stream=0x7ffc57b50f40) at
serialize.c:2175
#5 0x7fd82ba0bfa4 in do_unserializeFromConn (call=0x625000706cb8,
op=0x625298a8, args=, env=) at ser\
ialize.c:2628
#6 0x7fd82b8b5435 in do_internal (call=call@entry=0x625000706ba0,
op=op@entry=0x6250b678, args=, 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 = 0x300
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 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 Doneecho
> "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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Repeated segfault at installing sysdata.rda with clang/san build
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.
| 0x in ?? ()
| (gdb) bt
|
| #0 0x in ?? ()
| #1 0x5559317e61d4 in xdrmem_create ()
| #2 0x7fd82b9bd08b in R_XDRDecodeInteger (buf=) at
saveload.c:2246
| #3 0x7fd82ba007db in InInteger (stream=0x7ffc57b50f40) at serialize.c:425
| #4 0x7fd82b9ff743 in R_Unserialize (stream=0x7ffc57b50f40) at
serialize.c:2175
| #5 0x7fd82ba0bfa4 in do_unserializeFromConn (call=0x625000706cb8,
op=0x625298a8, args=, env=) at ser\
| ialize.c:2628
| #6 0x7fd82b8b5435 in do_internal (call=call@entry=0x625000706ba0,
op=op@entry=0x6250b678, args=, 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 = 0x300
|
| 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 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 Doneecho
"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
