@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.

@hwd8868 I had the same problem. Manually adding opencvtypes.py file into /usr/share/qtcreator/debugger/ resolved the problem

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?

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.

@JealousFish Yes, In Qt Creator is called “Build Directory”, where file .o are created and where you find your application. In the past I had the same issue, when I deleted the build folder the problem disappeared. Sometimes, when compiler failed and the code seems ok, I delete the builder folder and the problem disappears. I think, but it is only my idea, when this happens some files .o are locked, perhaps because I stopped the previous compile.

@kshegunov @mrjj Thanks for your explanation. Finally I figured out that the problem lay in the signal QGraphicsScene::changed I used. I learned about this signal in an OpenGL example in Qt. By using it I was trying to update my wave soon after its last update, however this signal could also be triggered by changing axis range or window resize, which would probably cause the crash for I didn't consider thread safety and synchronization under this condition. So I defined a custom signal function and now the problem is solved.

OK, seems like shadow casting on the default light might be broken. Turning it on caused the scene to crash.

@JonB Do not misunderstand. I have not said that I will not try your solution. I have just explained my temporary approach that I'm currently using to find the origin of my crashes. For the future I will take time to investigate more with the hope to have a generic solution to apply on all my VS solutions.

By build a debug version do you mean adding -DDEBUG -g to CFLAGS in my makefile? Hooray! Adding the -DDEBUG -g flags to my makefile fixed it! Thank you @aha_1980! I googled for this but nothing really came up, thanks!

@Sergey-I. said in Wrong char type detection in debugger: Has anyone reported this to the bug tracker? I don't know. Did you check that?

@mpergand Yes, this is just what I want. Thanks.

Ok, I've found that the results are stored in files Makefile.Release, Makefile.Debug and everything is explained here.

Thank you for your answer!

Hi and welcome to devnet, I am not aware of such a feature in Qt Creator except what is mentioned here but it doesn't mention keeping the thread being currently view. I'd recommend posting this question on the Qt Creator mailing list. You'll find there Qt Creator's developers/maintaines (this forum is more user oriented)

Did you activate any kind of compiler optimization?

Thank you, Charby! Do you mean Debugger settings/Enable QML? I know about it and suppose it is about Qml application. Am I right? But I ask about “mixed” mode – I can’t understand how to debug qml module which we call from C++ program ( p->runQmlPlugin() )?

Just in case, just had the same problem and in my case the problem was that windeployqt deployed wrong libraries (msvc ones instead of mingw despite being ran from mingw's qt build). Manual collecting libraries solved problem for me.

Alright. Thanks. That sounded like a lot of work so I scanned through the application's many features and found "Run Settings" has something called "Main QML file" that seems to operate the way I expect.