-2

I have C++ app that contains std::list of custom structs. However, in debug mode (release is working), app crashes after several calls of clear with

0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

inside library method void _Orphan_non_end() noexcept { // orphan iterators except end() and variable _Iterator_base12** _Pnextnext = &(*_Pnext)->_Mynextiter; is 0xdddddddddddddde5.

I cannot locate the problem nor create a minimal working example that will crash, so I guess the problem is somewhere else (heap corruption?) in the program. I have tried to run "Application Verifier" but with no luck. How can I find the source of the problem?

I am using Visual Studio 2022, Windows app, x64 mode

Martin Perry
  • 9,232
  • 8
  • 46
  • 114
  • 1
    Use after free. But without the part of your code that causes the problem we cannot really help. For example what does your struct look like. How do you create the list etc... – Pepijn Kramer Jun 09 '23 at 08:20
  • When I tried to create minimal example, use the struct, create few instances, add it to list and call clear, all worked correctly. So the list itself and struct probably are not the cause. I suspect some problem with memory corruption somewhere that maybe rewrites part of the list. – Martin Perry Jun 09 '23 at 08:24
  • @MartinPerry a memory corruption could explain it. But without a [mre] it's hard for us to help further. – wohlstad Jun 09 '23 at 08:29
  • I am just looking for a way how to debug it myself because I don't know any tool that can be used together with Visual Studio 2022 (and "Application Verifier" is not finding any problem) – Martin Perry Jun 09 '23 at 08:32
  • Is your code base huge? Do you still use manual new/delete in your code base, based on my experience it is often the cause of bugs like this. Consider refactoring new/delete to std::make_unique. Only use "raw" pointers in your code if you are sure they are non owning and can be nullptr (if the raw pointers must never be nullptr replace by references). As intermediate step : set any pointer to nullptr after a delete and then debug on nullptr dereferences (access violations). – Pepijn Kramer Jun 09 '23 at 08:33
  • Sadly, its large, and using some legacy code – Martin Perry Jun 09 '23 at 08:35
  • 3
    Have you unit tested your code in isolation? This will rule out rule out the problem is in your code. Because it really looks like the code is crashing due to some other part of the system. It also means I can't provide more help – Pepijn Kramer Jun 09 '23 at 08:37
  • Using WinDbg, you could specify a memory breakpoint which always breaks when someone accesses the memory. That'll be much easier with a vector, since the items are contiguous. You still have to deal with reallocations of the vector. Switching to a vector also changes the behavior. Which AV check did you enable? – Thomas Weller Jun 09 '23 at 08:59
  • 1
    "Release build is working" - forget that. Release build may appear to be working, but UB still is just UB. – Thomas Weller Jun 09 '23 at 09:00
  • Debug mode will [change deleted pointers](https://stackoverflow.com/questions/370195/when-and-why-will-a-compiler-initialise-memory-to-0xcd-0xdd-etc-on-malloc-fre) to *make it* crash. Release mode does not, so "works" by using an invalid pointer undetected. – BoP Jun 09 '23 at 09:12
  • From similar questions on stack overflow, the exact code is needed for debugging heap corruption. You may need memory debugging tools and check the use of std functions. – Minxin Yu - MSFT Jun 09 '23 at 09:48

1 Answers1

0

It seems I have found the problem.

The struct was inherited from parent whose destructor was not declared virtual. Adding virtual to parents' dtor fixed the problem.

Martin Perry
  • 9,232
  • 8
  • 46
  • 114