Windows cannot find *.cbp file; DDE bug (I think)

[ragnarok2040]

First off, I love your IDE, it's the best one I've used, especially with the compiler plugin.

I recently found a bug, although I'm not sure if it's caused by my system. When double-clicking a .cbp file, it opens fine in CodeBlocks, but Windows gives me a "Windows cannot find C:\Path\to\file.cbp" error. Disabling the DDE server for the .cbp filetype removes the error, though CodeBlocks then asks me to associate files again. The error doesn't come up for other filetypes associated with CodeBlocks. When the error occurs, I get a crash when exiting CodeBlocks.

AppName: codeblocks.exe ModName: ntdll.dll
ModVer: 5.1.2600.1217     Offset: 00019ecd

Exception Information:
Code: 0xc0000005 Flags: 0x00000000
Record: 0x0000000000000000 Address: 0x0000000077f69ecd

Hope this helps, .

[Anonymous]

Actually, the crash is occurring just by closing CodeBlocks too fast after opening a project file, heh. Not related to the other error, after all.

[mandrav]

Both bugs are known.
The DDE bug, I can't make anything of it. I don't know what windows expects from the app... As far as I can tell, codeblocks behaves as expected internally, but windows still gives this error, only if codeblocks isn't already running...

The "early shutdown" bug happens because there are still active class parsing threads. We 're working on it.

Thanx,
Yiannis.

[Anonymous]

Ahh, ok, . Clearing the DDE Message box fixes the problem, for a quick fix, although I don't know what that might affect. CodeBlocks seems to be fine with it.

[Anonymous]

Wasn't sure if this would be a known one, but, when opening a workspace that contains two large projects, this error occurs:

14:12:37: Can't create thread (error 8: not enough storage is available to process this command.)

I hope this helps :S..

[rickg22]

Hey, you're the guy who posted the bug on sourceforge! We've been searching for you to give us more info about your error-8 bug. Still there? (Regarding the early-shutdown bug, today I wrote an improved thread handling routine that will make that bug go and never return ;-). Hang tight...

[ragnarok2040]

Yep, still here. Beta7 gives this error now for just a single project, now. That one being the server project of the Single-Player Source SDK for Half-Life 2.

06:40:50: Can't create thread (error 8: not enough storage is available to process this command.)
06:40:50: Can not resume thread 0 (error 6: the handle is invalid.)
06:40:50: Can not wait for thread termination (error 6: the handle is invalid.)

It repeats around 800 times when importing both targets, but with the release target, it only occurs around 100 times. There are about 400 source files in the project, and 2,000 or more classes. The error doesn't seem to affect anything seriously, as the parsing finishes just fine from what I can tell, which works great in the new version . The only difference between the client project and server project is that the server project seems to have more files and classes.

Thanks for fixing that early shutdown bug, . It's been helpful as I've been opening and closing and opening and closing so much for the past couple hours since I got CodeBlocks 1.0Beta7 from testing that error's behavior.

[rickg22]

Now, THAT's giving information! But you still missed what OS you're using. Please put this info on the Sourceforge page and search for the "Can't create thread" bug report (NOTE: it's a closed bug, you need to change the search parameters).

See you there

[ragnarok2040]

K, I posted some more info along with my OS. I accidentally double posted with some more detailed info. on my second one. I didn't realize that I was supposed to be looking at the bug tracker instead of just the bugs list, lol. I created a SF account just now, so I won't do it again.

[mandrav]

the server project of the Single-Player Source SDK for Half-Life 2

Post a link to download and check it out.

There are about 400 source files in the project, and 2,000 or more classes.

LOL , codeblocks has more than 300 source files, not counting the resource files.

It's strange but it never happened to me. For example, the Ogre workspace contains 40+ projects. It takes a while to open it, with code-completion enabled, but it opens without errors...
If you can provide the download link, I will test it.

Yiannis.

[Anonymous]

Maybe it only happens to the half-life SDK?  :?: On the other hand, this may be Win2K specific. You might try adding a "win2k detection" routine and not schedule threads in that case. Anyway, ragnarok2040, you might try reducing the "maximum threads" to 1. (OK that'll make parsing AWFULLY SLOW,but it's an effective way to test!)

Do you have all the SP's installed?

[ragnarok2040]

Nah, just SP1. Setting maximum threads from 1 to 32 didn't have an effect on the error for the server project, :/. Raising the number did cause the client project to give the same error, though, I only tested at 32 and 16 At 16, there wasn't an error.

I'll post this on sourceforge's tracker, too.

[Anonymous]

I was wondering if that error (can't creat thread) was actually causing any problems or not.
Because I don't know what I'm doing I can't get HL2 to compile, and was wonder if that error was doing anything or not.
One more thing ruled out.
I'm on XP SP2 so it's not just 2K.

[mandrav]

I was wondering if that error (can't creat thread) was actually causing any problems or not.

No, it's not. It only has to do with the class browser parsing the project files. Nothing to do with the compiler...

Yiannis.