test-c-api: some dynamic arrays errors on PPC (likely due to size of bool assumption being 1 byte: it is 4 byte on Darwin ppc32)

[barracuda156]

R version 4.2.2 (2022-10-31) -- "Innocent and Trusting"
Copyright (C) 2022 The R Foundation for Statistical Computing
Platform: powerpc-apple-darwin10.8.0 (32-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> # Workaround for loadNamespace() failure on R 3.2
> requireNamespace("rlang")
Loading required namespace: rlang
> 
> library("testthat")
R(28119,0xa0dfb620) malloc: *** error for object 0xa0d51754: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0xa0d517c4: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e52c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e4928: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e4890: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e48dc: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e47c8: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e46a0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e45c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e4630: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e44f8: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e5200: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e5380: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e538c: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
R(28119,0xa0dfb620) malloc: *** error for object 0x34e53a8: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
> library("rlang")

Attaching package: 'rlang'

The following objects are masked from 'package:testthat':

    is_false, is_null, is_true

> 
> test_check("rlang")

[ FAIL 6 | WARN 0 | SKIP 227 | PASS 3674 ]

══ Skipped tests ═══════════════════════════════════════════════════════════════
• !rmarkdown::pandoc_available() is TRUE (2)
• Disabled (1)
• Failing (1)
• Not on Windows (1)
• On CRAN (217)
• R7 cannot be loaded (1)
• Skipping on big-endian platform. (2)
• getRversion() >= "4.0" is TRUE (1)
• profmem must be installed. (1)

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test-c-api.R:860'): can grow and shrink dynamic arrays ────────────
arr[[2]] (`actual`) not equal to `exp` (`expected`).

`actual`:   "00" "00" "00" "00" "00" "00"
`expected`: "00" "01" "01" "00" "00" "01"
── Failure ('test-c-api.R:870'): can grow and shrink dynamic arrays ────────────
arr[[2]] (`actual`) not equal to `exp` (`expected`).

`actual`:   "00" "00" "00" "00" "00" "00"
`expected`: "00" "01" "01" "00" "00" "01"
── Failure ('test-c-api.R:890'): can resize dynamic arrays ─────────────────────
arr[[2]] (`actual`) not equal to bytes(1, 0) (`expected`).

`actual`:   "00" "00"
`expected`: "01" "00"
── Failure ('test-c-api.R:900'): can resize dynamic arrays ─────────────────────
arr[[2]][1:2] (`actual`) not equal to bytes(1, 0) (`expected`).

`actual`:   "00" "00"
`expected`: "01" "00"
── Failure ('test-c-api.R:901'): can resize dynamic arrays ─────────────────────
dyn_unwrap(arr) (`actual`) not equal to bytes(1, 0) (`expected`).

`actual`:   "00" "00"
`expected`: "01" "00"
── Failure ('test-cnd-handlers.R:103'): drop_global_handlers() works and is idempotent ──
out$out (`actual`) not equal to chr() (`expected`).

actual vs expected
- "R(28476,0xa0dfb620) malloc: *** error for object 0xa0d51754: pointer being freed was not allocated"
- "*** set a breakpoint in malloc_error_break to debug"
- "R(28476,0xa0dfb620) malloc: *** error for object 0xa0d517c4: pointer being freed was not allocated"
- "*** set a breakpoint in malloc_error_break to debug"
- "R(28476,0xa0dfb620) malloc: *** error for object 0x34e52c0: pointer being freed was not allocated"
- "*** set a breakpoint in malloc_error_break to debug"
- "R(28476,0xa0dfb620) malloc: *** error for object 0x34e4928: pointer being freed was not allocated"
- "*** set a breakpoint in malloc_error_break to debug"
- "R(28476,0xa0dfb620) malloc: *** error for object 0x34e4890: pointer being freed was not allocated"
- "*** set a breakpoint in malloc_error_break to debug"
and 20 more ...

[ FAIL 6 | WARN 0 | SKIP 227 | PASS 3674 ]
Error: Test failures
Execution halted

System info: macOS 10.6.8 Rosetta (ppc32), gcc 12.2.0, R 4.2.2 +builtin_lapack+cairo+gcc12+openmp+recommended+tcltk+x11

P. S. malloc errors are a known issue caused by duplicate libstdc++; those are unlikely to cause test errors.

[lionel-]

Can you please tell me more about the system you're using (ppc32)?

malloc errors are a known issue caused by duplicate libstdc++; those are unlikely to cause test errors.

Do you mean the malloc errors at the start of the session are not unexpected? My first thought reading the report is that those were caused by rlang on load (via RProfile or other). So they're not technically part of the report right?

From a cursory look, the tests do point to a fundamental problem. If you're indeed trying to port R on a non standard platform, can you please investigate and see if rlang does anything wrong.

[barracuda156]

@lionel- Thank you for responding!

Re malloc errors: they are part of the report, but are not specific to either R or rlang. Within R, they occur with a number of packages, though not all. Reasons are explained here by a GCC developer: https://github.com/iains/darwin-toolchains-start-here/discussions/20

Re platform: this is on macOS 10.6.8, building for ppc (32-bit, Big endian). (Yes, this is an old system, but we actively support it in Macports.)

I am very much interested to have rlang fixed: it is one of the fundamental ports. Could you advise me how to proceed with debugging?

[barracuda156]

@lionel- I am looking at the code in the test now; does it assume size of Bool to be 1 byte? That will explain failures: Bool is 4 bytes on Darwin ppc32. Ref: http://personal.denison.edu/~bressoud/cs281-s07/MacOSXLowLevelABI.pdf (page 9)

[lionel-]

yup good find, I think we do assume single bytes for bools in these tests.

[lionel-]

According to https://stackoverflow.com/a/5067749/1725177, gcc has a switch to use size-1 bools.

[barracuda156]

yup good find, I think we do assume single bytes for bools in these tests.

@lionel- I do not know how to make a specific fix for that though :) In principle, either there should be a test for a size of bool or otherwise it should be defined conditionally, like:

#if defined __APPLE__ && defined __ppc__
. . .
#else
. . .

[lionel-]

We can either skip these tests, and risk reintroducing an issue in the future because we're not actively testing against this kind of platform, or you could compile with size-1 bools. Up to you.

Since I don't have much time for this, I'll probably skip the whole c-api file on your platform.

[barracuda156]

We can either skip these tests, and risk reintroducing an issue in the future because we're not actively testing against this kind of platform, or you could compile with size-1 bools. Up to you.

Since I don't have much time for this, I'll probably skip the whole c-api file on your platform.

If this issue only affects tests but not rlang performance otherwise, we can live with that.

[barracuda156]

@lionel- Just to make sure, this error is only test-related, should not break anything with rlang functionality otherwise?

[lionel-]

I think so but I haven't reviewed all our code across all our packages (rlang and vctrs in particular) for size > 1 bools. PPC32 support is extremely low priority and has already taken up too much time.

The fact that the other tests seem to pass in your report is a good sign though.

[barracuda156]

I think so but I haven't reviewed all our code across all our packages (rlang and vctrs in particular) for size > 1 bools. PPC32 support is extremely low priority and has already taken up too much time.

The fact that the other tests seem to pass in your report is a good sign though.

Thank you.

Yeah I don’t expect any active maintenance, as long as nothing is broken on purpose, minor incompatibilities can be handled on our end.