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

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

1.0 Stopped.jpg

2.0 Thread 1.jpg

3.0 Thread 0.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

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.