View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0018468||Lazarus||IDE||public||2011-01-11 18:41||2012-02-08 09:10|
|Reporter||Alexander Shishkin||Assigned To||Martin Friebe|
|Priority||normal||Severity||trivial||Reproducibility||have not tried|
|Product Version||0.9.31 (SVN)||Product Build|
|Target Version||1.0.0||Fixed in Version||0.9.31 (SVN)|
|Summary||0018468: IDE does not close handle of project folder on project close|
|Description||I opened some project closed it and open another and attempted to delete first project. All files were deleted except project folder. Lock detection tool shows opened handle of closed project folder.|
i368-win32-win32 0.9.31 28909 svn
|Tags||No tags attached.|
|Fixed in Revision||35229|
||A first hunch, because of setting the currentdir somewhere in the process.|
Does this is still happen?
Please try resetting the debugger (from the run menu)
||Yes, resetting debugger helps. Lock detection shows lock of exe output folder by gdb.|
- Which version of windows to you use?
- And which version of GDB? (even if you installed a new snapshot, your configuration may still point to a older GDB version, so please check)
- it assume you have updated your Lazarus in the meantime, so this does still happen with a recent snapshot?
Using windows vista and GDB 7.3, I was not able to reproduce.
Keeping GDB open (even if the project is changed) is intentional. Depending on the user's system spec, this may safe time, when the user starts debugging.
||WinXp SP3, GDB 7.3, Lazarus rev 34764.|
need to send gdb a
-environment-cd <new project>
The problem is probably more extensive. It can happen when:
- project is closed/changed
- "save project as" to a new directory
- "run params" > "working directory" is used
- maybe others
In each case the debugger would need to be updated on changes (or appropriate conditions). This would slow down the IDE, including any OS/gdb combination that does not have the issue.
A new option exists, since rev 34925, allowing to reset the debugger after each run.
If the directory locking is an issue, please enable this option. The debugger will then always release the directory (since gdb is unloaded from memory)
It does mean that gdb needs to be loaded each time (instead of just the first time) when an app is started in the debugger. Depending on your system this may or may not result in slower start of the debugger.
I consider this option a fix to the problem.
Unless good reason are given why it is not, I will resolve this issue soon.
I added an automated reset, if the project is changed.
If you keep the project, but save all files to a new directory, then you must reset the debugger yourself.
|2011-01-11 18:41||Alexander Shishkin||New Issue|
|2011-01-11 18:41||Alexander Shishkin||Widgetset||=> Win32/Win64|
|2011-01-11 19:07||Vincent Snijders||LazTarget||=> 1.0|
|2011-01-11 19:07||Vincent Snijders||Note Added: 0045109|
|2011-01-11 19:07||Vincent Snijders||Status||new => acknowledged|
|2011-01-11 19:07||Vincent Snijders||Target Version||=> 1.0.0|
|2012-01-20 03:16||Martin Friebe||Note Added: 0055869|
|2012-01-20 10:12||Alexander Shishkin||Note Added: 0055879|
|2012-01-20 16:55||Martin Friebe||Status||acknowledged => assigned|
|2012-01-20 16:55||Martin Friebe||Assigned To||=> Martin Friebe|
|2012-01-20 16:56||Martin Friebe||Note Added: 0055893|
|2012-01-20 16:56||Martin Friebe||Status||assigned => feedback|
|2012-01-20 18:13||Alexander Shishkin||Note Added: 0055895|
|2012-01-20 19:44||Martin Friebe||Note Added: 0055896|
|2012-01-20 19:44||Martin Friebe||Status||feedback => assigned|
|2012-01-25 16:22||Martin Friebe||Note Added: 0056038|
|2012-01-25 16:22||Martin Friebe||Status||assigned => feedback|
|2012-02-07 23:29||Martin Friebe||Fixed in Revision||=> 35229|
|2012-02-07 23:29||Martin Friebe||Status||feedback => resolved|
|2012-02-07 23:29||Martin Friebe||Fixed in Version||=> 0.9.31 (SVN)|
|2012-02-07 23:29||Martin Friebe||Resolution||open => fixed|
|2012-02-07 23:29||Martin Friebe||Note Added: 0056646|
|2012-02-08 09:10||Alexander Shishkin||Status||resolved => closed|