-1

I'm having trouble understanding somethiong. So I have a method that uses a std::for_each with a lambda function. In this lambda function, I do a dynamic_cast. That's just for a little context. This dynamic_cast crashes. I am not asking why it crashes or how to fix it because I know (I did a dynamic_cast on an object that was deleted). My question is why this crashes only in debug mode (in Qt) ?

I understand why it crashes in debug, but I don't understand why it doesn't crash in release. I had a similar problem few weeks ago on a different code, but both time, the crash was a segmentation fault. Is it because a segfault is an undefiened behaviour and this behaviour is different between debug and release ?

Thanks.

Franck
  • 19
  • 3
  • 5
    Undefined Behavior is fun. It allows the compiler to turn non working code into "working" code. – NathanOliver Nov 08 '18 at 15:11
  • Perhaps it helps to review the definition of the word "undefined". Per the C++ standard it means *there are no restrictions on the behavior of the program*, and in plain English it means *not clearly or precisely shown, described, or limited*. So, undefined behavior implies that you **can't expect anything in particular**. Thus: your expectation that the code could crash is inconsistent with the meaning of the word "undefined": you make the word mean something that it doesn't. – Kuba hasn't forgotten Monica Nov 09 '18 at 18:08

2 Answers2

0

I'm assuming you're running Linux. If so, you could use gdb (do compile with the -g flag). Set a breakpoint at the dynamic cast. You can then step into each following function. Perhaps this can give you a better understanding of the difference between debug and release mode in qt.

Here is a good overview of useful gdb commands.

Bruno Hendrickx
  • 354
  • 2
  • 14
0

I think you have a memory leak or memory grout. You can try to use Valgrind to find suspicious and dangerous places in your program.

Also check that you correctly use ASSERT instructions and the like in your framework. The expression inside ASSERT should not affect the logic of the program, because in release, many ASSERT implementations are not executed.

break1
  • 137
  • 6