CB Bugs?

[Max]

Dear *,

I would like to flag an issue (well, two issues) using CB (latest nithgly build 2189 , Windows XP SP2 and Windows 2000).

I have the following environment variables

TEMP=C:\Temp
TMP=C:\Temp

Using CB I got a lot of xxx.tmp in the Temp directory. Closing CB they are not deleted. My understanding is that the files are
temporary files, for some reason they are not deleted closing CB.

After several weeks I got a lot of empty temporary files that I must delete manually.

I observed this issue in the past with every nightly build since two months (previously I used DevCpp)

Observing C:\Temp directory it seems that one xxx.tmp file is created (empty) during the CB startup and it will never
be deleted closing CB.
 

Is this behaviour a CB bug?


Another issue is :

I have the "allow only one running instance" flag selected. If I start another instance of CB, having CB already open, I got

1) An empty temporary file in C:\Temp  (an old friend  )
2) A crash

Hereafter the DrMinGW reprot

codeblocks.exe caused an Access Violation at location 6184421e in module codeblocks.dll Reading from location 00000000.

Registers:
eax=00000000 ebx=00c3bf20 ecx=00000007 edx=00000000 esi=004b8030 edi=0022ebbc
eip=00000000 esp=0000000c ebp=00000004 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202

Call stack:
00000000


In the past I got a simple warning message. This should be a bug.

Any confirmation?

Bye

Max

[thomas]

Is this behaviour a CB bug?

The effect you see probably comes from the DevPak plugin.

There are 4 occasions where tempfiles are created:
1. Makefile creation: there is a bug in the compiler plugin during Makefile creation, the tempfile is never deleted, but then Makefile creation is not enabled anyway, so it does not matter for now.
2. DevPak plugin: tempfiles are only deleted if decompression of a package failed, this is a bug (and the likely cause)
3. Code completion: works properly (but is not exception safe)
4. Application startup: works properly (but is not exception safe)

Occasions 3 and 4 may leave behind a temp file if the application crashes in between creation and deletion. There is not much one can do, unluckily (a smart tempfile object could work around this, but the likelihood of failure is pretty close to zero, so the effort is not in relation to the benefit).

Occasion 2, on the other hand, will regularly leave tempfiles.
The DevPak plugin has a couple of issues anyway. Tiwag has already identified a few such things. After the great job he did to Find and Replace, maybe we can convince him to give DevPak an overhaul, too