@MHuysmans I think it is intended behaviour. But whatever it should have nothing to do with Qt Creator. That is only a front-end to whatever debugger you use. Which you don't say. So go test this behaviour in the debugger, e.g. gdb with step and next commands.

Hi, Are you using the same stack on macOS ?

@JonB Thanks Jon. I will look into those suggestions. I think at this point though, the best thing for me to try, rather than thrashing around with my current project, would be for me to start a new project focused on just replicating this specific issue. I'll try and pare this down to minimal required code, just enough to reproduce the problem This will make findings clearer and easier to communicate to others. If I get to a point where I have something useful to share, I'll do so. Thank you again..Mark

I may have found the key condition for this: inconsistent capitalization between the file on disk and the entry in your project file. My project is all CMake, and CMakeLists.txt specified a capital letter in the parent directory of the source file; but it was in lower case on disk. Bug report here: https://bugreports.qt.io/browse/QTCREATORBUG-27123 Related: https://bugreports.qt.io/browse/QTCREATORBUG-18007

@Christian-Ehrlicher I've no idea :D But it did not work. When I pause debug, I get symbols/etc but it says that symbols are different from source file... so I have to manually navigate to cpp file in qt/src/bla/bla/bla dir Feels like msvc DLL shipped with Qt does not match src that I can install... maybe I should build my own qt so that everything is definitely running one ver... odd. Still digging.

Thanks for this hint. Very useful for debugging purposes. Appreciate the help :)

Sorry, I hadn't come back to trying this for a while. I was able to get past this by dropping -optimize-size, but ran into other strange issues, primarily where a purely debug build had a bunch of errors and a mixed config build would not create the debug lib files (likely due to the same cause, just the errors didn't show or halt the build for some reason) even though the process appeared to complete successfully. Not having much luck with Qt6 it seems, which is a shame since I'd really like to make use of the upstream changes I submitted for it. Luckily at this point MSVCs internal CMake version has been updated to one that is compatible with Qt6, so the manual replacement is no longer needed. I'm currently trying to build 6.1 and was able to get past the configure step, though I had to disable tests (which this time I wanted to confirm it built correctly) due to QTBUG-88829, so I'll see if I have better luck this time. If the mixed build doesn't work I'll try just a debug one again to see if there are the errors I had before, or if not so that I can compile tests and see what might be failing.

I had the same problem. [Solved] Qt version 6.4.3 and Qt Creator 11.0.2 on Ubuntu 22.04 running in a VMware virtual machine. The error happens when switching to the system terminal window (console application under Linux) right after the launch of the debugging session. In my case opencvtypes.py was already in place. In Edit -> Preferences -> Environment -> System parameter 'Terminal' was set to: /usr/bin/x-terminal-emulator by default and its sub-parameter Command line arguments used for "Run in terminal" was set to -e again by default. I tried to change the -e parameter with no success, but when returned to the default values the problem was vanished.

I think I have the same problem. The application stops when a breakpoint is encountered but there is no debug information. I discovered an inconvenient workaround described below. Set breakpoint Run the application in Debug. The debugger stops but doesn’t show the yellow arrow at breakpoint. The Debugger Log indicates the application has stopped. Local variables are not shown. Stack window does not show any information. In the debugger pane, the “Threads” is at #0. The yellow arrow can be shown at the breakpoint if I change “Threads” to some other number (e.g. #1) which displays assembly code in the editor with the yellow arrow visible. When changing “Threads” back to #0, the yellow arrow at the breakpoint is visible in the editor. Local variable are displayed. Pressing F10 (Step Over) advances to the next line of code but the yellow arrow, local variables and stack info disappear. Windows 10 Creating a desktop application Qt Creator v4.13.0, based on Qt 5.15.0, built Aug 25, 2020 Any suggestions on how to resolve this problem? [image: 4c07736a-b3de-4b25-aea6-ddd8ebfe80e5.jpg] [image: 4591ab0a-88e0-4220-a64f-45451627a0d3.jpg] [image: e688f262-bcdf-40e1-8b52-2198b7643492.jpg]

Hi. I think it just for a static QObject like QFile in Application ... It can solve with static function to create a static object in first call...

@sierdzio I think you're second option is correct. I did dumpbin /dependents on both the debug and release versions of my util, and they have the same release QT dlls. I guess I never had to step into the QT code :-) . Usually, I get link errors when mixing debug with release, stemming from different array instrumentations. Sounds like QT was careful about this, to allow the mixing of debug with release -- unix-like.

@JKSH Yes, I created two simple console applications and added required libraries to them. Compiler keys are identical. I checked carefully. A one project have a mistake, and another doesn't have For example, a project with subprojects have this error, but QT Widgets does not have (but not always). Heisenbug?

@jsulm Yep, absolutely, there is much to read/fiddle with, and may not be portable. May or may not work for OP's particular case. Anyway, whether this or your core dump suggestion (OP should look up how his target Linux OS handles core dumps allowed or not), he has a few approaches to consider now....

Hi and welcome to devnet, How are you building your executable ? What version of PyQt5 and Qt are you using ? Since you are using PyQt, you might want to consider contacting its authors.