LuciferYang commented on issue #67871:
URL: https://github.com/apache/doris/issues/67871#issuecomment-5634744242
Some follow-up that narrows this, and rules out half of the hypothesis I
posted above.
The register dump in the report identifies the callee. `rdi` is the buffer
and `rsi` is `0x100`, which is the 256-byte cap absl applies right before the
call (`size_t to_read = std::min<size_t>(buffer_size, 256); int result =
getentropy(buffer, to_read);`). So the jump to address 0 is the `getentropy`
call itself, not something further down.
The "libc has no getentropy" branch is out. The failing build's runtime libc
is `/lib64/libc.so.6` with Build ID `75e396c6440f382892765e8f24e2e0fc93800163`,
which is glibc 2.28 out of the build image, and it exports
`getentropy@@GLIBC_2.25`.
What is asymmetric is how the two symbols bind in an ASAN build of
`doris_be_test`:
```
2083: 10d80f2f 5 FUNC WEAK DEFAULT 16 getentropy # ASAN's
__interceptor_trampoline_getentropy
868: 10e4e6b0 56 FUNC GLOBAL DEFAULT 16 getrandom #
be/src/glibc-compatibility/musl/getrandom.c
```
`musl/getrandom.c` is force-linked through the
`glibc-compatibility-explicit` OBJECT library, so Doris's definition wins.
`musl/getentropy.c` stays in the `glibc-compatibility` static archive and is
not pulled in, so the name is left to ASAN's interceptor. A RELEASE build of
the same tree does link ours (`getentropy`, GLOBAL, 139 bytes), so this
asymmetry is specific to the sanitizer build.
That is not yet the whole story. I built a standalone ASAN probe in the same
image with the same symbol shape, Doris's `getrandom.c` object plus ASAN's
`getentropy` trampoline, calling `getentropy` on a spawned thread, and it
returns normally on this host. So the binding shape alone is not sufficient and
something else about the full link matters. I could not take it further without
a full ASAN link of the tree.
The candidate fix that follows from this is one line: move
`musl/getentropy.c` into the `glibc-compatibility-explicit` OBJECT library next
to `musl/getrandom.c`, for the reason the comment there already gives about
archive scan order. Then `getentropy` is a strong definition in the binary and
the call cannot land on 0, and the sanitizer build matches what the RELEASE
build already does. I have not proven that it fixes the crash, since I cannot
reproduce it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
