Defect in Carbide C++ 1.2: linking faisl because a process doesn't release a dll or e

[svdwal]

When doing a lot of debugging in Carbide C++ 1.2, staring the emulator in debugging mode, stopping it, editing and rebuilding etc, after some time Carbice c++ fails to link the resulting executable, saying that some other process has locked.

Exiting and restarting Carbide C++ then makes this error go away for one or two iterations but it will always come back.

The process that is hlocking the executable to be linked happens to be DE.exe. Killing DE.exe from the windows task manager results in the execulate becoming linkable again. But then starting the debugger fails the first time, but switching back to the carbide C++ view and pressing F11 again makes the emulator showing itself immediately.

Sander van der Wal
www.mBrainSoftware.com

[Nokia Ron]

The problem most likely is you did not end the Debugger/Executable in the correct order. It is a pretty common error people just forget where they are at. If you are sure you are always ending the debug session correctly you might want to report a bug, but this is pretty common when repeatedly building and debugging over and over.

Ron

[tsone]

I have a similar issue with Carbide.C++ 1.2

I can't make modifications to a MyApp application which I have first debugged and then closed in emulator. This is because an another process (probably DE.EXE or epoc.exe) is using MyApp.exe file. This is what Carbide's Problems-view shows:

Error creating file: MyApp.exe[]
mwldsym2.exe: The process cannot access the file because it is being used by another process.

I have closed MyApp in emulator but not the emulator itself. Of course I could work around this by starting emulator every time I debug, but that would probably double my development time

Is this a flaw in carbide or just my stupidity? I've heard that codewarrior doesn't have this problem...

[augustbering]

What is the "correct order"? I always get this error and need to kill de.exe, even whith on-device debugging.

[mgroeber9110]

I have a similar issue with Carbide.C++ 1.2

I can't make modifications to a MyApp application which I have first debugged and then closed in emulator. This is because an another process (probably DE.EXE or epoc.exe) is using MyApp.exe file.

I discussed this quite at length with the Carbide developers, after having had the same problem, and it seems that there are several possible layers to this issue:

• Some recent fixes made in Carbide.c++ 1.2.1 to prevent the debugger from holding on to the .exe for too long even after it has exited: I found that the problem would go away in several circumstances after I used the "Update" feature in Carbide to get the latest version - I am surprised that the availability of this hasn't been announced more widely, but it is publicly downloadable. Check Help | About to see if the version reported is 1.2.1 Build 4. If not, use Help | Software Updates to get it.
• Delayed release of some binaries by the emulator: this is apparently an emulator bug in 3rd Edition - you can see on the modules tab that, even after closing an EXE, it is still listed as "loaded" for quite a long time.
• Problems with multiple targets: if you have more than one EXE and DLL in your project, only the one listed as Debug Target MMP in the Project Settings will be released after it exists, while all the others are kept open by DE.EXE even after they disappear from the Modules tab.

Of course, in some obscure cases, like ECom and other plugins, the OS itself may cling to the last instance of a released DLL, or not allow you to unload it at all without a reboot, but this is not something that you should be concerned with for a normal application.

[augustbering]

Great! Now I don't even have to close the emulator before relinking. Thanks!

[jplauril]

I discussed this quite at length with the Carbide developers, after having had the same problem, and it seems that there are several possible layers to this issue:

• Delayed release of some binaries by the emulator: this is apparently an emulator bug in 3rd Edition - you can see on the modules tab that, even after closing an EXE, it is still listed as "loaded" for quite a long time.

Would you have a reference to this?

I'm struggling with not being able to restart an application reliably. The application in question links to a DLL with WSD, and running the application works once only. Subsequent invocations fail with the error -5 KErrNotSupported. Listing the loaded DLLs with Sysinternals "listdlls" utility shows that the DLL in question remains loaded after the application exits.

But -- after waiting for a few minutes it starts working as expected! The DLL is unloaded immediately after the application exits and you can rerun it with no problems.

Ideas? Workarounds? Is there a way to force the unloading of the DLL on application exit or am I just out of luck?

[mgroeber9110]

Would you have a reference to this?

Unfortunately not - I got this information from some private discussions with the Carbide developers, who said that nothing could be done about it for now, but that they had reported a bug against the emulator.