C++ Logo


Advanced search

Re: [std-proposals] set_new_handler extension

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Fri, 17 Feb 2023 12:07:33 -0500
On Fri, Feb 17, 2023 at 12:00 PM Phil Bouchard via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> On 2/17/23 11:54, Thiago Macieira wrote:
> > On Friday, 17 February 2023 08:43:15 PST Phil Bouchard wrote:
> >> Well despite what Jason said earlier, there are 15,500 hits for a search
> >> engine search such as Google on the subject:
> >> https://www.google.com/search?q=rtlfreeheap+crash
> >
> > This search is meaningless. It finds people reporting crashes that ended in
> > RtlFreeHeap, not that RtlFreeHeap has a problem.
> >
> > I kept getting assigned the vast majority of pointer bugs in Qt because they
> > ended with a null pointer consumption inside of the QBasicAtomicPointer class.
> > But it wasn't a QBasicAtomicPointer bug; the bug had happened way before where
> > a null pointer was dereferenced.
> Well it doesn't matter because again when I use the GPU memory manager
> then everything runs fine.

You realize that this proves precisely nothing, right? The source of
the bug could still be in your code. Switching memory allocators means
switching where the heap tracking stuff is (and a GPU allocator
probably puts heap tracking in your CPU's memory rather than GPU
memory of which there is far less). So a wild-write which on one
allocator hits heap tracking data, would very likely miss heap
tracking data on a different allocator. It would hit something else,
something that your program is able to tolerate better.

Received on 2023-02-17 17:08:30