Just a rant...
Author
Having no one else to complain about this to, I must say that after almost 6 hours tracking down a bug that rises in release mode in my application (which runs fine -- if you consider 9 fps fine -- in debug mode), I want to stick a gun in whoever is responsible mouth's and not only pull the trigger, but make sure he swallon a lot of powder before blowing his f&C* head of.
Of course, the one responsible is no one other than myself, so this make matters worse since I'm not really into S&M. But man, it sucks!
The deal is that a pointer to class which has a member that is a enum (and, as far as I can tell, a integer at run-time, right?) blows up on any access in release mode. After I removed that part of the code (which is necessary for script bug checking but not to keep the program running), I find out that another thing is exploding in my face, a class that inherits from std::map. So I stop trying to do things "the hard way", and switch the class to a delegated pattern (now the map is member, not father), but the damn code still bugs. So I'm currently removing the smart pointer that I was using to access the class, but, as I said, after 6 hours dealing with this infame bug, most surely he will no go away. I think my program is cursed.
I hope moderators do not erase this post...
In C++, a class has to be designed ahead of time to be extensible through inheritance. In most cases, classes in the Standard C++ Library are not so designed. Specifically, an inheritable class needs to have a virtual destructor, and I don't think any of the Standard C++ Library types have them.
Have you run your release code in the debugger and single-stepped it? Debug mode builds initialize all memory to false values, for instance, whereas release mode won't. This could be the source of some access violations. You can build a release mode app with debug information and then run it in the debugger so you can single-step and all the other good stuff to determine exactly where the problem occurs and then why.
Have you run your release code in the debugger and single-stepped it? Debug mode builds initialize all memory to false values, for instance, whereas release mode won't. This could be the source of some access violations. You can build a release mode app with debug information and then run it in the debugger so you can single-step and all the other good stuff to determine exactly where the problem occurs and then why.
Author
I've actually not tried to use the debugger with the release version. It's incompatible with most optimizations that are my primary concern... but I will try it.
About inheriting the std::map, well, I just created it because I needed a specific destructor to the class. But now that you've said it, probably the lack of a virtual destructor would cause a good memory leak. But I've already solved this part of the problem.
I'll attempt to debug the release code (paradoxical...). Thanks for sheding a light, I was already losing my hair over this.
About inheriting the std::map, well, I just created it because I needed a specific destructor to the class. But now that you've said it, probably the lack of a virtual destructor would cause a good memory leak. But I've already solved this part of the problem.
I'll attempt to debug the release code (paradoxical...). Thanks for sheding a light, I was already losing my hair over this.
Quote:Original post by Oluseyi
Have you run your release code in the debugger and single-stepped it? Debug mode builds initialize all memory to false values, for instance, whereas release mode won't. This could be the source of some access violations. You can build a release mode app with debug information and then run it in the debugger so you can single-step and all the other good stuff to determine exactly where the problem occurs and then why.
This is a good avice, but the OP has to consider that some optimizations may produce very strange results (vars that seems uninitialized are instead stored in a registry, non-useful code has been removed, and so on). To be able to fully debug some release code, you must have at least some basic knowledge of assembler.
Regards,
Erm. I've never had a problem returning an enum value in debug or release mode. And yes, in general, they are all upcast to an integral type after compilation. I assume you mean something like this:
Just interested in whether (1) I'm way off or (2) there is something else wierd going on.
enum SomeEnum { SOME_ENUM_VALUE, ...};class SomeClass { ...public: SomeEnum GetSomeValue(void) const {return val;} ...private: SomeEnum val;};Just interested in whether (1) I'm way off or (2) there is something else wierd going on.
I can't help much, but this is the first time I've seen a Symphony X quote on here so :), and here's what I can think of:
The things you mention don't sound like things that are actually the direct cause of the problem. There's nothing wrong with debugging in release mode but you've got to realise that it won't get you a lot closer to the source of the crash than what function it occurs in (ignoring inlining). If you're using Linux (which I doubt, since you don't mention any compiler/OS info), I'd say valgrind is the solution to all problems.
I'm guessing there's some kind of invalid read/write access going on which causes the crash. The best thing I can think of is to try and track down where that pointer is stored, locate where it is crated and set a watchpoint to see where it is overwritten to an invalid pointer (assuming this is what's happening). It's tricker in release than debug but still entirely possible. Anyway, presumably you get some kind of error message from the debugger/OS when your program crashes, so please post what it is.
Anyway - be thankful it doesn't cause your computer to hang completely (if it doesn't?). I just spent two days trying to track down a bug which turned out to be out of bounds array access on my graphics card!
The things you mention don't sound like things that are actually the direct cause of the problem. There's nothing wrong with debugging in release mode but you've got to realise that it won't get you a lot closer to the source of the crash than what function it occurs in (ignoring inlining). If you're using Linux (which I doubt, since you don't mention any compiler/OS info), I'd say valgrind is the solution to all problems.
I'm guessing there's some kind of invalid read/write access going on which causes the crash. The best thing I can think of is to try and track down where that pointer is stored, locate where it is crated and set a watchpoint to see where it is overwritten to an invalid pointer (assuming this is what's happening). It's tricker in release than debug but still entirely possible. Anyway, presumably you get some kind of error message from the debugger/OS when your program crashes, so please post what it is.
Anyway - be thankful it doesn't cause your computer to hang completely (if it doesn't?). I just spent two days trying to track down a bug which turned out to be out of bounds array access on my graphics card!
I'm with ZQJ. It sounds like there's a decent chance that you're corrupting memory. If that's the problem than you could spend tons of time chasing down the symptom instead of the cause. I'd make sure the memory you're accessing looks valid.
-John
-John
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
