octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #61472] AddressSanitizer crash in MEX tests


From: Markus Mützel
Subject: [Octave-bug-tracker] [bug #61472] AddressSanitizer crash in MEX tests
Date: Mon, 6 Dec 2021 06:10:14 -0500 (EST)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.55 Safari/537.36 Edg/96.0.1054.43

Follow-up Comment #26, bug #61472 (project octave):

By the looks of it, a compiler (or its preprocessor) can claim to be C++17
complete even if the C++ standard library it will be using doesn't implement
all features.

Anyhow, I'm with jwe on this. It looks like a proper fix will be quite
intrusive. We'd need to raise the minimum requirements quite significantly
(libstdc++ version 9 or newer, no support for libc++ currently).
Alternatively, we'd need to introduce a new dependency on the boost libraries.
(It needs confirmation if this is an actual option.)
In any case, it looks like the changes will be too significant to squeeze into
Octave 7 without delaying its release (possibly substantially).

For Octave 7, should we just leave it as it is and be aware that the mex
interface might work unexpectedly with certain combinations of compiler
versions/C++ library versions/platforms/... at certain operations? As far as
we currently can tell, a normal user might not notice anything about this on
most (if not all?) platforms because the C++ standard libraries probably
implement `delete` on top of `free`...

If we are using `delete[]` though, anything might happen ranging from memory
leaks to freeing a huge amount of memory (resulting in loads of dangling
references or crashing immediately). This is because `delete[]` seems to read
the memory in front of where the pointer points to find how much memory to
actually free. In general, that could be anything for malloc-ed data.
See e.g. this for how it is implemented in MS compilers (but I'm assuming
other compilers don't do it much differently):
https://devblogs.microsoft.com/oldnewthing/20040203-00/?p=40763

IIUC, the oct interface isn't affected by any of this.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61472>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]