error: cannot open output file

[nekkceb]

After running my code in debug mode, stop the process and make changes, when I try to rebuild or re-run in the debugger I get this compiler error:
:-1: error: cannot open output file dynamicspline.exe: Invalid argument.
There is an old post related to this, but in that case, it seems they could find the process still running in the task manager. My application is a windows GUI, not a console application, and I do not see any processes related to it in the task manager that I can kill. The only thing that works for me is to exit QTCreator, then find the build directory (e.g. build-dynamicspline-Desktop_Qt_6_2_8_MinGW_64_bit-Debug) and rename it to something like 'jumk'.. I can then re-start Qt-Creator, re-buiuld and ruyn again. But this is a pain to deal with. AND it just started, i was working fine a few days ago!
Windows 10, latest build, Qt Creator 11.0.0, compiling with Desktop Qt 6.2.8 MinGW 64-bit

[nekkceb]

This post is deleted!

[Axel Spoerl]

@nekkceb
Technically speaking, Windows blocks your binary while being executed in the debugger. That makes sense, you don't want to change horses on the fly.

When that happens to me on Linux, kilall gdbhelps. The MinGW debugger should also be gdb. If you kill this process, you should be fine.

The interesting question is: Why doesn't the application shut down cleanly?
The two most popular reasons are:

• (1) Something inheriting from QObjectis (soft-)leaking, which keeps the event loop spinning after everything else has shut down.
• (2) Application shutdown calls a slot, that blocks the event loop (e.g. by waiting for something that doesn't happen).

It's worth to investigate this, e.g. by closing the application and then setting a break point in QGuiApplication::processEvents(). If an event gets delivered to a QObject, you can investigate what it is and why it is still alive.
If the break point doesn't kick in, application code is blocking it. You have to spill loads of qDebug() << __FUNCTION__ << this << "some info"; in every shutdown step to see where it hangs.

[nekkceb]

@Axel-Spoerl Thanks for the quick response. I dont see any thing unusual in src code that might 'keep spinning' to block the shutdown. Looking at task manager, I do see a gdb.exe and gdborig.exe running, under the heading of QtCreator, but only when my program is running, and these both disappear when I stop it, either from the close 'X' in upper right, or using the QtCreator to stop the debugger.
When you say to put a breakpoint in
QGuiApplication::processEvents(),
I did not install Qt by building from source. Will it work to over-ride QGuiApplication just to create a processEvents I can set a breakpoint in?
Why was this working fine no more than a few days ago??
BTW I am modifying one of the examples here. Although I have expanded it a bit, it is still a pretty small project.
!

[Axel Spoerl]

@nekkceb
QCoreApplication::processEvents()is not virtual, so you can't override it.
You can use the Qt Maintenance tool to install Qt with sources and debug symbols. That way you can step into Qt code without having to build it.

Which example are you using? Just to make sure, that you haven't caught us red-handed ;-)

[nekkceb]

@Axel-Spoerl Thanks I'll try your suggestion. I started with the dynamicspline example for QChart. I am expanding on it considerably to figure out various features of QChart, so it is not likely something in the original source! On the other hand, I dont see how anything I added would cause a background 'run-on' that would prevent the debugger stopping.

[nekkceb]

@Axel-Spoerl I hate to say it but this is getting worse. I just re-opened a major project using Qt 5.15.13, and the same thing happens. AND, these are all new developments in the last week. It is as if I stumbled on setting something in QtCreator that I should not have, but I do not recall even looking at preferences recently. I can re-build and run the project initially, but if I try to re-build it, the .exe appears to be locked somehow and I cant delete it, thus getting message from the build system the the file is in use. i have run the Task manager, cant find either gdb or the executable running. I have also run the program 'tasklist' from a cmd window to find it, no avail. The only thing to do is re-boot, which is a pain everytime I want top update the executable.
I also just ran the Qt Maintenance tool to install with source and debug as you indicate, but I cant find a way to do that with existing installs. Is there a check box or some other way of setting an install option that I am missing?

[Axel Spoerl]

@nekkceb

[nekkceb]

@Axel-Spoerl Sorry, missed the little drop-down arrows! Seems I already have the debug info.

[Axel Spoerl]

@nekkceb
No worries. I am curious to learn what you observe!

[nekkceb]

@Axel-Spoerl Well, I apologize, but I am not expert in debugging compiler issues. I cant see how to do a breakpoint as you suggest, I tried stepping into the .exec function, but that did not do anything. Looks like I am going to have to live with this rather bizarre new behavior or rely on someone more expert to figure it out!

[nekkceb]

@Axel-Spoerl I found a solution that works much better than re-booting the computer between each debug cycle. Turns out opening a cmd-prompt, cd to the directory with the offending .exe file and just enter del <filename>.exe /f does the trick!
However, I still wonder why this behavior started all of a sudden about a week ago, no recent updates to either Windows or Qt. I probably fat-fingered a setting somewhere in Qt, but have not been able to find it so far.

[JonB]

@nekkceb
Does it require you use the /f option? If so, that forces deleting of read-only file, which (unlike Linux) Windows/cmd does not allow you to do directly, it requires you make it non-read-only first. If the file being created is somehow being marked read-only then it would not surprise me that Creator or whatever does not do this and expects to open the file directly.

How that relates to the .exe you are producing I do not know, nor why it has just started happening. But see whether the file is read-only and/or you have to use del /f to delete it, that's a clue.

BTW, do you use a virus scanner? It is possible that is looking at generated .exe files, worth switching it off or telling it to ignore the build directory.

[nekkceb]

@JonB Thanks for the ideas. Turns out the /f option is not needed. But things are certainly strange! If I try to delete the file in the Windows File Explorer, I get this message:

Note I tried to do this after stopping the program in the debugger AND closing QtCreator. The file is NOT marked as read-only, though windows thinks it is 'open' somehow. Using the cmd-prompt, just issue a del BIPSMain.exe deletes it and allows me to rebuild it in QtCreator.

[Axel Spoerl]

@nekkceb
Is BIPS20 your project / BIPSMain.exe your executable?
If so: It's in use by gdbor however the MinGW derivate is called.

[JonB]

@nekkceb said in error: cannot open output file:

del BIPSMain.exe deletes it and allows me to rebuild it in QtCreator.

(Now that we know /f/read-only is not the issue.) Then you are fortunate. Clearly something has it open in some shape or form, in which case Windows does not normally allow to delete the file. So this is surprising but convenient.

If you really are sure tasklist/taskman cannot find the executable file still running, and you still want to know what is going on, you could download whatever currently works for Windows which allows you to view open handles in the OS. There used to be a procman and/or procexplorer (or similar names) from sysinternals for this, if they don't work I imagine there are alternatives now.

[nekkceb]

@Axel-Spoerl Agree, you have mentioned that before, but neither BIPSMain nor gdb are found in the Task Manager, or (per @JonB suggestion) the procexp64.exe from sysinternals. Both do appear in the TaskManager when the debug session is running, but both go away when the application exits. So, I am truly at a loss, but knowing I can just delete BIPSMain use the del command in a DOS-box helps a lot.

[JonB]

@nekkceb
If you have got procexp64 or similar working, instead of look for executable running it has something which lets you pick a file and find all "open handles" into it. That really ought find dynamicspline.exe with a handle!

Or, from error message

:-1: error: cannot open output file dynamicspline.exe: Invalid argument.

the invalid argument might just indicate that the file "does not exist" or "half exists", is in a funny state so that it cannot be overwritten but can be deleted.... Anyway, that's me out of suggestions now.

[nekkceb]

This post is deleted!