public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
@ 2021-03-31 9:00 keith.halligan at microfocus dot com
2021-03-31 9:40 ` [Bug c++/99845] " rguenth at gcc dot gnu.org
` (11 more replies)
0 siblings, 12 replies; 13+ messages in thread
From: keith.halligan at microfocus dot com @ 2021-03-31 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Bug ID: 99845
Summary: gcc8: Overloaded operator new[](size_t, const
std::nothrow_t&) is seg faulting when the allocation
fails
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.halligan at microfocus dot com
Target Milestone: ---
Created attachment 50490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50490&action=edit
Disassembly of the crash
In our code we're facing a crash on gcc (c++) 8. The example program below
demonstrates the crash. The crash seems to come from some incorrect machine
instructions that follow calling operator new[](). The issue occurs when a
new(nothrow) fails to allocate a block of memory, and the 0/null value is then
dereferenced, on the other hand if the allocation succeeds, the memory address
is valid and can be sucessfully dereferenced.
The example code uses a few levels of "operator new[]() - std::nothrow_t
version" before we finally call out to the c++ runtime version of operator
new(size_t, const std::nothrow_t&).
==
// File: new_crash.cpp
#include <cstdint>
#include <limits>
#include <new>
class MemAlloc {
public:
MemAlloc() {}
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return ::operator new(sz, nt);
}
};
template <typename T>
class VarArray : public MemAlloc
{
public:
VarArray() {}
~VarArray(){}
static T*
allocbuf(uint32_t nelems) {
return new(std::nothrow) T[static_cast<size_t>(nelems)];
}
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return MemAlloc::operator new[](sz, nt);
}
};
class MyType {
public:
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return MemAlloc::operator new[](sz, nt);
}
uint32_t m_id;
VarArray<int> m_int_seq;
};
class MyTypeList : private VarArray<MyType>
{
public:
using VarArray<MyType>::allocbuf;
using VarArray<MyType>::operator new[];
};
int main()
{
const uint32_t max_uint32t = std::numeric_limits<uint32_t>::max();
MyType *type_list = MyTypeList::allocbuf(max_uint32t);
if (type_list) {
delete[] type_list;
}
return 0;
}
==
Compiled via: g++ -o m64 -O2 new_crash new_crash.cpp
Disassembly (attached) generated via: objdump -M X86-64 -M att -d -C
--no-show-raw-insn new_crash > new_crash.dis
at -O2 level:
0000000000400650 <main>:
400650: sub $0x8,%rsp
400654: mov $0x600dd8,%esi
400659: movabs $0x800000000,%rdi
400663: callq 400640 <operator new(unsigned long, std::nothrow_t
const&)@plt>
400668: mov $0xffffffff,%edx
40066d: mov %rdx,(%rax)
^^^^
Dereferening $rax leads to seg fault as it contains
a zero value
at -O0 level:
00000000004008dd <VarArray<MyType>::allocbuf(unsigned int)>:
4008dd: push %rbp
4008de: mov %rsp,%rbp
4008e1: push %r13
4008e3: push %r12
4008e5: push %rbx
4008e6: sub $0x18,%rsp
4008ea: mov %edi,-0x24(%rbp)
4008ed: mov -0x24(%rbp),%ebx
4008f0: movabs $0xfffffffffffffff,%rax
4008fa: cmp %rax,%rbx
4008fd: ja 40092c <VarArray<MyType>::allocbuf(unsigned int)+0x4f>
4008ff: lea 0x1(%rbx),%rax
400903: shl $0x3,%rax
400907: mov $0x600dd8,%esi
40090c: mov %rax,%rdi
40090f: callq 400878 <MyType::operator new[](unsigned long,
std::nothrow_t const&)>
400914: mov %rax,%r12
400917: mov %rbx,(%r12)
^^^^
Dereferening $r12, which has a zero value which
originated in $rax
--
Compilation (verbose):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--disable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -E -quiet -v -D_GNU_SOURCE
new_crash.cpp -m64 -mtune=generic -march=x86-64 -O2 -fpch-preprocess -o
new_crash.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward
/usr/lib/gcc/x86_64-redhat-linux/8/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -fpreprocessed new_crash.ii
-quiet -dumpbase new_crash.cpp -m64 -mtune=generic -march=x86-64 -auxbase
new_crash -O2 -version -o new_crash.s
GNU C++14 (GCC) version 8.3.1 20191121 (Red Hat 8.3.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.3.1 20191121 (Red Hat 8.3.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.3.1 20191121 (Red Hat 8.3.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.3.1 20191121 (Red Hat 8.3.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6b667c67be32d4821a98ef9960b6da95
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
as -v --64 -o new_crash.o new_crash.s
GNU assembler version 2.30 (x86_64-redhat-linux) using BFD version version
2.30-79.el8
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/8/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/8/:/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/collect2 -plugin
/usr/libexec/gcc/x86_64-redhat-linux/8/liblto_plugin.so
-plugin-opt=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
-plugin-opt=-fresolution=new_crash.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--no-add-needed --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o new_crash
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/8/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/8
-L/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/8/../../.. new_crash.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/x86_64-redhat-linux/8/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib64/crtn.o
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-m64' '-O2' '-o' 'new_crash'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
--
Apologies if I chose the wrong component to file this bug under, perhaps libgcc
would be better, it seems relevant to the c++ code generating backend, change
as required.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
@ 2021-03-31 9:40 ` rguenth at gcc dot gnu.org
2021-03-31 9:46 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-31 9:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2021-03-31
Status|UNCONFIRMED |NEW
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
allocbuf(uint32_t nelems) {
return new(std::nothrow) T[static_cast<size_t>(nelems)];
}
expands to
<<cleanup_point return <retval> = TARGET_EXPR <D.7342, SAVE_EXPR <(sizetype)
nelems> <= 1152921504606846975 ? (size_t) ((SAVE_EXPR <(sizetype) nelems> + 1)
* 8) : (size_t) __cxa_throw_bad_array_new_length ()>;, TARGET_EXPR <D.7341,
MyType::operator new [] (NON_LVALUE_EXPR <D.7342>, (const struct nothrow_t &)
¬hrow)>;;, *(sizetype *) NON_LVALUE_EXPR <D.7341> = SAVE_EXPR <(sizetype)
nelems>;, try
{
...
which calls MyType::operator new[] and then stores 'nelems' at the beginning
of the allocated storage for some reason (ABI?).
That makes using new[] (std::nothrow) "unsafe" to call it seems?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
2021-03-31 9:40 ` [Bug c++/99845] " rguenth at gcc dot gnu.org
@ 2021-03-31 9:46 ` jakub at gcc dot gnu.org
2021-03-31 9:50 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-31 9:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> allocbuf(uint32_t nelems) {
> return new(std::nothrow) T[static_cast<size_t>(nelems)];
> }
>
> expands to
>
> <<cleanup_point return <retval> = TARGET_EXPR <D.7342, SAVE_EXPR <(sizetype)
> nelems> <= 1152921504606846975 ? (size_t) ((SAVE_EXPR <(sizetype) nelems> +
> 1) * 8) : (size_t) __cxa_throw_bad_array_new_length ()>;, TARGET_EXPR
> <D.7341, MyType::operator new [] (NON_LVALUE_EXPR <D.7342>, (const struct
> nothrow_t &) ¬hrow)>;;, *(sizetype *) NON_LVALUE_EXPR <D.7341> =
> SAVE_EXPR <(sizetype) nelems>;, try
> {
> ...
>
> which calls MyType::operator new[] and then stores 'nelems' at the beginning
> of the allocated storage for some reason (ABI?).
Yes
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies
(not just ABI but also for the reason the ABI talks about).
>
> That makes using new[] (std::nothrow) "unsafe" to call it seems?
I guess for the nothrow versions we should wrap that nelems store into a
COND_EXPR based on whether operator new returned non-NULL.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
2021-03-31 9:40 ` [Bug c++/99845] " rguenth at gcc dot gnu.org
2021-03-31 9:46 ` jakub at gcc dot gnu.org
@ 2021-03-31 9:50 ` rguenth at gcc dot gnu.org
2021-03-31 10:47 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-03-31 9:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The interesting thing is that doing
#include <new>
struct X
{
~X(){}
};
int main(int argc, char **argv)
{
X *p = new (std::nothrow) X[argc];
}
properly conditionalizes this store:
TARGET_EXPR <D.6173, operator new [] (NON_LVALUE_EXPR <D.6174>, (const struct
nothrow_t &) ¬hrow)>;;, (struct X *) D.6173 != 0B ? *(sizetype *)
NON_LVALUE_EXPR <D.6173> = SAVE_EXPR <(sizetype) argc>;, (struct X *) (D.6173 +
8); : (struct X *) D.6173;)
so something in the wrapping triggers the error.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (2 preceding siblings ...)
2021-03-31 9:50 ` rguenth at gcc dot gnu.org
@ 2021-03-31 10:47 ` redi at gcc dot gnu.org
2021-03-31 11:40 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 10:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=98798
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe related to Bug 98798 comment 4, where G++ fails to store a cookie when
required to. If not related, it's probably worth fixing them together.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (3 preceding siblings ...)
2021-03-31 10:47 ` redi at gcc dot gnu.org
@ 2021-03-31 11:40 ` redi at gcc dot gnu.org
2021-03-31 11:52 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 11:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:
namespace std {
using size_t = decltype(sizeof(0));
struct nothrow_t { } const nothrow = { };
}
void* operator new(std::size_t);
void* operator new[](std::size_t);
void operator delete(void*) noexcept;
void operator delete[](void*) noexcept;
void operator delete(void*, std::size_t) noexcept;
void operator delete[](void*, std::size_t) noexcept;
void* operator new(std::size_t, const std::nothrow_t&) noexcept;
void* operator new[](std::size_t, const std::nothrow_t&) noexcept;
void operator delete(void*, const std::nothrow_t&) noexcept;
void operator delete[](void*, const std::nothrow_t&) noexcept;
extern "C" int printf(const char* ...);
using std::size_t;
struct X
{
void* operator new[](size_t sz, const std::nothrow_t& nt) {
return ::operator new(sz, nt);
}
unsigned data = 0;
};
struct Y
{
static X* alloc(unsigned n) { return new(std::nothrow) X[n]; }
};
int main()
{
Y::alloc(-1u);
}
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (4 preceding siblings ...)
2021-03-31 11:40 ` redi at gcc dot gnu.org
@ 2021-03-31 11:52 ` redi at gcc dot gnu.org
2021-03-31 11:53 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 11:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Keith Halligan from comment #0)
> class MemAlloc {
> public:
> MemAlloc() {}
> void* operator new[](size_t sz, const std::nothrow_t& nt) {
> return ::operator new(sz, nt);
> }
Why is this function written as an overloaded operator new?
You never use it for new-expressions like `new MemAlloc[n]` so why isn't it
just a normal named member function that allocates memory?
It isn't the cause of the bug, but it is confusing to have this extra operator
new[] involved that is a red herring.
It should probably be something like:
struct MemAlloc {
static void* alloc(size_t sz) {
return ::operator new(sz, std::nothrow);
}
};
and then just call it as a normal static member function:
void* operator new[](size_t sz, const std::nothrow_t&) {
return MemAlloc::alloc(sz);
}
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (5 preceding siblings ...)
2021-03-31 11:52 ` redi at gcc dot gnu.org
@ 2021-03-31 11:53 ` redi at gcc dot gnu.org
2021-03-31 12:02 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 11:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Keith Halligan from comment #0)
> class MyType {
> public:
> void* operator new[](size_t sz, const std::nothrow_t& nt) {
Your bug is here. This need to be noexcept.
Passing std::nothrow_t doesn't tell the compiler that this is a nothrow-new,
only making it noexcept does that. So the compiler assumes this will throw on
failure, and so a non-exceptional return is always non-null.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (6 preceding siblings ...)
2021-03-31 11:53 ` redi at gcc dot gnu.org
@ 2021-03-31 12:02 ` redi at gcc dot gnu.org
2021-03-31 16:36 ` msebor at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Alternatively, compile with -fcheck-new to tell the compiler that *all*
operator new overloads can return a null pointer. That means it always checks
for null, even for overloads that are declared as potentially-throwing. This is
probably not what you want to do, you probably just need to use 'noexcept' in
the right places.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (7 preceding siblings ...)
2021-03-31 12:02 ` redi at gcc dot gnu.org
@ 2021-03-31 16:36 ` msebor at gcc dot gnu.org
2021-03-31 17:23 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: msebor at gcc dot gnu.org @ 2021-03-31 16:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |msebor at gcc dot gnu.org
--- Comment #9 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Keith Halligan from comment #0)
> > class MyType {
> > public:
> > void* operator new[](size_t sz, const std::nothrow_t& nt) {
>
> Your bug is here. This need to be noexcept.
This seems like it might be worth warning about.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (8 preceding siblings ...)
2021-03-31 16:36 ` msebor at gcc dot gnu.org
@ 2021-03-31 17:23 ` redi at gcc dot gnu.org
2021-04-06 7:35 ` keith.halligan at microfocus dot com
2021-04-06 11:35 ` redi at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-31 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=99851
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #9)
> This seems like it might be worth warning about.
Requested as PR 99851
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (9 preceding siblings ...)
2021-03-31 17:23 ` redi at gcc dot gnu.org
@ 2021-04-06 7:35 ` keith.halligan at microfocus dot com
2021-04-06 11:35 ` redi at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: keith.halligan at microfocus dot com @ 2021-04-06 7:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Keith Halligan <keith.halligan at microfocus dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #11 from Keith Halligan <keith.halligan at microfocus dot com> ---
I am re-opening this issue as there seems to be a bug with the 32-bit code
generation that I'm after noticing.
While adding noexcept to the "opeator new[]()" overloaded functions does stop
the crash on 64-bit, it does nothing for the 32-bit code, with the compiler
attempting to throw a std::bad_alloc.
Below is a version of Jonathan Wakeley's modified testcase that has noexcept on
the "operator new[]()".
$ cat bug99845.cpp && g++ -m32 -O1 -o bug99845 bug99845.cpp
namespace std {
using size_t = decltype(sizeof(0));
struct nothrow_t { } const nothrow = { };
}
void* operator new(std::size_t);
void* operator new[](std::size_t);
void operator delete(void*) noexcept;
void operator delete[](void*) noexcept;
void operator delete(void*, std::size_t) noexcept;
void operator delete[](void*, std::size_t) noexcept;
void* operator new(std::size_t, const std::nothrow_t&) noexcept;
void* operator new[](std::size_t, const std::nothrow_t&) noexcept;
void operator delete(void*, const std::nothrow_t&) noexcept;
void operator delete[](void*, const std::nothrow_t&) noexcept;
extern "C" int printf(const char* ...);
using std::size_t;
struct X
{
void* operator new[](size_t sz, const std::nothrow_t& nt) noexcept {
return ::operator new(sz, nt);
}
unsigned data = 0;
};
struct Y
{
static X* alloc(unsigned n) { return new(std::nothrow) X[n]; }
};
int main()
{
Y::alloc(-1u);
}
==
$ ./bug99845
terminate called after throwing an instance of 'std::bad_array_new_length'
what(): std::bad_array_new_length
Aborted (core dumped)
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/99845] gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
` (10 preceding siblings ...)
2021-04-06 7:35 ` keith.halligan at microfocus dot com
@ 2021-04-06 11:35 ` redi at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-06 11:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99845
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Keith Halligan from comment #11)
> While adding noexcept to the "opeator new[]()" overloaded functions does
> stop the crash on 64-bit, it does nothing for the 32-bit code, with the
Clearly not "does nothing" since the behaviour changes.
> compiler attempting to throw a std::bad_alloc.
No, not bad_alloc:
> terminate called after throwing an instance of 'std::bad_array_new_length'
> what(): std::bad_array_new_length
You've asked for an array of -1u objects of size 4, which is four times larger
than the entire address space on 32-bit x86. That makes the new-expression
erroneous, and what GCC does is exactly what the C++14 standard requires.
C++17 was changed by https://wg21.link/cwg1992 but GCC doesn't implement that
yet, which I've reported as Bug 99934.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2021-04-06 11:35 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-31 9:00 [Bug c++/99845] New: gcc8: Overloaded operator new[](size_t, const std::nothrow_t&) is seg faulting when the allocation fails keith.halligan at microfocus dot com
2021-03-31 9:40 ` [Bug c++/99845] " rguenth at gcc dot gnu.org
2021-03-31 9:46 ` jakub at gcc dot gnu.org
2021-03-31 9:50 ` rguenth at gcc dot gnu.org
2021-03-31 10:47 ` redi at gcc dot gnu.org
2021-03-31 11:40 ` redi at gcc dot gnu.org
2021-03-31 11:52 ` redi at gcc dot gnu.org
2021-03-31 11:53 ` redi at gcc dot gnu.org
2021-03-31 12:02 ` redi at gcc dot gnu.org
2021-03-31 16:36 ` msebor at gcc dot gnu.org
2021-03-31 17:23 ` redi at gcc dot gnu.org
2021-04-06 7:35 ` keith.halligan at microfocus dot com
2021-04-06 11:35 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).