User forums > Using Code::Blocks

SVN version 4475 crashes on exit

<< < (2/2)

Biplab:

--- Quote from: Ceniza on September 18, 2007, 08:39:33 pm ---I'll try to reproduce it in Windows again (I tried already, but it didn't crash).

--- End quote ---

I faced this crash a number of times. So I just reverted the codes that has been changed in between. Just try it for couple of times. :)

Ceniza:
Don't worry, I set it to use only 1 CPU in VMware, and now it crashes :)

Ceniza:
You know what... I'll just leave it like that. It seems to work most of the time in Windows, it's usable in *nix (even though I bet it's the cause of the many "Aborted" exits I get) and very few people are using this IDE in Mac (where this situation is even worse, making CC useless (yes, I've tried CB in Mac)).

Every single attempt I made to get something coherent in that piece of code that wouldn't be subject to race conditions fired a new crash somewhere else, because of another "race condition". I would try to redesign some of those pieces of code, but, once again, I don't have enough time now. In addition, modifying that code easily fires crashes under different situations in different platforms, so I won't touch it for now (at least it's usable like it is right now).

ironhead:
The 4478 build (which I assume contains the reverted code) works like a charm.

Thanx for the quick fix! :)

thomas:
Ceniza talked with me about this already, but I guess it's worth posting a note for everyone else again :)

Please do not tamper with any code only to make Valgrind [insert any other analysis tool] happy.
(print this in poster size and hang it over your bed)

While it is true that Valgrind [iaoat] may help you spot leaks and other errors, it is intrinsically stupid. It knows nothing about the programmer's intent or the program's normal mode of operation.
It may give a hint if you're looking for a problem. It may even give you a hint if you're just profiling the program to "clean up". Those hints may be very valuable, too.
However, output from a diagnosis tool must never be seen as a mandatory "must fix" issue. Often, those warnings or errors will be false positives, and if you "fix" the problem, you will break the program.

Now, about Code Completion and semaphores, I must admit that I've never understood the tampering that's being done there (especially not why it depends on the platform when a semaphore should signalled). Personally, I would have chosen a different design from the beginning, abstracting the whole thread stuff into a class that does that, and only that (as in FileManager, for example).
But whatever it is, the present implementation more or less works. So, unless someone is willing to rewrite that whole big ugly thing from scratch, I'd recommend to not touch it. Tampering with something one doesn't understand (and I assume none of us really understands) most often makes things worse.

Navigation

[0] Message Index

[*] Previous page