emscripten-core / emscripten-core/emscripten
Crash on iOS Safari wasm - two references to the same object return different values from trivial accessor for a primitive field.
- Dominant language
- C++
- Stars
- 27.6k
- Forks
- 3.6k
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 105
Description
Hi all, I'm filing this bug after exhausting many other options. I'm running a wasm binary with link time optimization and have tried running with `ASSERTIONS`, `SAFE_HEAP`, `STACK_OVERFLOW_CHECK`, and `--memoryprofiler` on emscripten. I've also run with an address sanitizer (`--copt=-fsanitize=address --linkopt=-fsanitize=address`), both in native and wasm builds. This bug reproes 100% of the time on iOS Safari, but not on Android, native Mac OS, or desktop Chrome + Safari
But, on to the bug. Here you can see we take two references to the same object in a vector:
```
class Object {
...
uint32_t id() const { return id_; }
...
uint32_t id_ = 0;
};
std::vector objs_;
void f() {
auto &o1 = objs_.at(idx);
...
auto &o2 = objs_.at(idx);
...
if (std::addressof(o1) == std::addressof(o2) && o1.id() != o2.id()) {
printf("Same object but different values! (%p and %p) (%zu and %zu)", &o1, &o2, o1.id(), o2.id());
}
...
}
```
We then check if their address is the same but the value of `id()`, which is a trivial accessor for a primitive field, is different - which it is:
```
Same object but different values! (0xb472c8 and 0xb472c8) (3676866271 and 0)
```
The worst part about this bug is that it manifests itself when I change seemingly unrelated code, specifically changing a destructor from an empty user-defined destructor `~Foo() {}`, to a default destructor `~Foo() = default;`. I've diff-ed the bitcode before link time optimization with both destructors, and they are the same. So it seems perhaps somewhere in LTO there is a memory issue being introduced.
As an extra hurdle, this bug is resistant to inspection. If I try to print out the memory around `o1` or `o2`, then the bug no longer occurs.
```
for (int i = 0; i < 128; ++i) {
printf("%02x ", (unsigned char*)&o1 + i);
}
```
The impact of this bug is that our program is crashing because later when we access the object, the `id()` is zero. I have not been able to recreate this with a minimal repro case, but posting this in the hope others have seem something similar or have suggestions on investigating further.
Details:
- iOS Safari
- C++ wasm with link time optimization
- emsdk-sdk-2.0.27
- llvm 8ae5e0b154ae18a78f73c0aef58356002b8ff0d7
- (added later) WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=231364
Contributor guide
Assessment
This issue has not been assessed yet.