×

Discussion Board

Results 1 to 8 of 8
  1. #1
    Registered User
    Join Date
    Mar 2003
    Posts
    148

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

    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

  2. #2
    (Retired) Nokia Developer Admin.
    Join Date
    Jan 2006
    Location
    Michigan
    Posts
    4,664

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

    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

  3. #3
    Registered User
    Join Date
    Jan 2006
    Posts
    2

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

    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:

    Code:
    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...

  4. #4
    Registered User
    Join Date
    Dec 2003
    Posts
    11

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

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

  5. #5
    Registered User
    Join Date
    Mar 2003
    Location
    Germany
    Posts
    200

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

    Quote Originally Posted by 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.
    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.

  6. #6
    Registered User
    Join Date
    Dec 2003
    Posts
    11

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

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

  7. #7
    Super Contributor
    Join Date
    Dec 2004
    Posts
    643

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

    Quote Originally Posted by mgroeber9110 View Post
    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?

  8. #8
    Registered User
    Join Date
    Mar 2003
    Location
    Germany
    Posts
    200

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

    Quote Originally Posted by jplauril View Post
    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.

Similar Threads

  1. GoogleIt
    By deepika.mangla in forum Symbian
    Replies: 5
    Last Post: 2011-05-28, 11:04
  2. Linking with a DLL using estlib.lib (a.k.a. stdlib or libc) causes a kernel fault
    By pekangas in forum Carbide.c++ IDE and plug-ins (Closed)
    Replies: 42
    Last Post: 2009-03-13, 06:28
  3. Breakpoints don't work when attaching a dll to server process in Carbide v1.2
    By robinhuang in forum Carbide.c++ IDE and plug-ins (Closed)
    Replies: 1
    Last Post: 2007-08-31, 14:39
  4. DLL Capability issues
    By sid.baral84 in forum Symbian
    Replies: 8
    Last Post: 2006-12-13, 05:19
  5. Linking Static DLL with another Static DLL
    By symbianfresher in forum Symbian
    Replies: 6
    Last Post: 2006-01-09, 04:23

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×