SIGSEGV under DenseMapBase::erase after std::bad_alloc #85281
Comments
|
As far as I know LLVM generally does not try to be exception-safe. It is compiled with In Fedora we enable |
Hm, no, I misremembered: We use Whether With that in mind, your idea of catching the exception in allocate_buffer and explicitly aborting sounds reasonable to me. |
Previously, it called `::operator new` which may throw `std::bad_alloc`, regardless of whether LLVM itself was built with exception handling, and this can cause safety issues if outside code has destructors that will call back into LLVM. Now we use `::operator new(..., nothrow)` and call `llvm::report_bad_alloc_error` when allocation fails, which will abort when LLVM is built without exceptions. Ref: llvm#85281
|
See #85449. However, I just noticed that LLVM does have a |
Oh, that's a great find! So that's how OOM is supposed to be handled. I'm not sure we really want everything in InitLLVM, but it looks like we should at least be calling install_out_of_memory_new_handler(). |
Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? `@nikic`
Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? `@nikic`
Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? ``@nikic``
Rollup merge of rust-lang#122574 - cuviper:llvm-oom, r=nikic Register LLVM handlers for bad-alloc / OOM LLVM's default bad-alloc handler may throw if exceptions are enabled, and `operator new` isn't hooked at all by default. Now we register our own handler that prints a message similar to fatal errors, then aborts. We also call the function that registers the C++ `std::new_handler`. Fixes rust-lang#121305 Cc llvm/llvm-project#85281 r? ``@nikic``
Ref: rust-lang/rust#121305
In that Rust issue, running on an
i686host, I found thatDenseMap::allocateBuckets->llvm::allocate_buffer->operator newwas throwingstd::bad_alloc. Then when unwinding runs the destructors intoLLVMContextDispose, we get back intoDenseMapBase::eraseand hitSIGSEGV, presumably in the same instance that failed allocation.Maybe
allocate_buffershould catch and callreport_bad_alloc_errorlike thesafe_*allocfunctions do? But even so, it seems that some part ofDenseMapis not exception safe.The text was updated successfully, but these errors were encountered: