My problem is twofold:
- When quitting a certain application programmed using SDL, the
application makes it clear to a final printf before the final return
main(), closes the window, and appears to behave normally. However,
viewing the process list (Windows XP) shows that it is indeed still
running (as does the debugger).
- Being a closed source commercial application, I cannot give out any
code specifically from this application. I have been trying to
replicate this behavior to no avail.
So here’s where you guys come in: Does anyone know of any reason that
SDL would maintain a program after SDL_Quit() has been called? There
are no child threads still active, at least not that the code for the
program itself generated. This problem first began to exhibit itself
after including SDL_syswm.h (that I was aware of) but continues to be
present after removing all references to it. When attempting to close
the application via the IDE (code::blocks) I get a message box stating
"unspecified error". Thanks in advance.
-Elden
Well, I found the problem. It was a matter of destructor not being
called when free() was called on a malloc’ed array. The issue was
solved by using vectors and explicitly calling the proper destruction
code in a loop. I feel I have to impress upon anyone new to
programming, and even those new to game programming, how important
debugging, profiling, and testing of an application is. Here’s a small
bit of code I can show from the source:
std::vector<p_Bubble> g_BubbleS(Count);
std::vector<C2DSprite> g_BubbleG(Count);
/* using the vectors */
...
/* cleaning up, removing surface, etc */
for (int i_Remove = 0; i_Remove < g_BubbleS.size(); i_Remove++) {
g_BubbleS[i_Remove].g_Remove(); };
/* etc */
This code is from the particle emitter that was creating the problem in
the application. Apparently the only thing keeping the application
running was a bit of allocated memory for the surface in each element, a
32x32 image. This is a really easy bug to overlook, and had my
development environment not balked at the idea of replacing a file that
was in use, I would still be unaware of the issue. Finding the issue
took approximately 9 hours, since there are literally thousands of lines
of code, and no error was thrown. I can only hope that this helps
someone else.
Remember, debugging is great…but ALWAYS test, test, test!
-Elden
Elden Armbrust wrote:> My problem is twofold:
- When quitting a certain application programmed using SDL, the
application makes it clear to a final printf before the final return
main(), closes the window, and appears to behave normally. However,
viewing the process list (Windows XP) shows that it is indeed still
running (as does the debugger).
- Being a closed source commercial application, I cannot give out any
code specifically from this application. I have been trying to
replicate this behavior to no avail.
So here’s where you guys come in: Does anyone know of any reason that
SDL would maintain a program after SDL_Quit() has been called? There
are no child threads still active, at least not that the code for the
program itself generated. This problem first began to exhibit itself
after including SDL_syswm.h (that I was aware of) but continues to be
present after removing all references to it. When attempting to close
the application via the IDE (code::blocks) I get a message box stating
"unspecified error". Thanks in advance.
-Elden
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Elden Armbrust wrote:
Well, I found the problem. It was a matter of destructor not being
called when free() was called on a malloc’ed array. The issue was
solved by using vectors and explicitly calling the proper destruction
code in a loop. I feel I have to impress upon anyone new to
programming, and even those new to game programming, how important
debugging, profiling, and testing of an application is. Here’s a small
bit of code I can show from the source:
If you stopped using malloc and free in a C++ application it would have been
even better. Rule number 1 in C++ : never ever use malloc and free,
especialy to allocate memory for C++ objects with constructor and
destructor !
And don’t forget that all “new []” pointers must be destroyed with “delete
[]” too.> std::vector<p_Bubble> g_BubbleS(Count);
std::vector<C2DSprite> g_BubbleG(Count);
/* using the vectors */
...
/* cleaning up, removing surface, etc */
for (int i_Remove = 0; i_Remove < g_BubbleS.size(); i_Remove++) {
g_BubbleS[i_Remove].g_Remove(); };
/* etc */
This code is from the particle emitter that was creating the problem in
the application. Apparently the only thing keeping the application
running was a bit of allocated memory for the surface in each element, a
32x32 image. This is a really easy bug to overlook, and had my
development environment not balked at the idea of replacing a file that
was in use, I would still be unaware of the issue. Finding the issue
took approximately 9 hours, since there are literally thousands of lines
of code, and no error was thrown. I can only hope that this helps
someone else.
Remember, debugging is great…but ALWAYS test, test, test!
-Elden
Christophe Cavalaria wrote:
Elden Armbrust wrote:
Well, I found the problem. It was a matter of destructor not being
called when free() was called on a malloc’ed array. The issue was
solved by using vectors and explicitly calling the proper destruction
code in a loop. I feel I have to impress upon anyone new to
programming, and even those new to game programming, how important
debugging, profiling, and testing of an application is. Here’s a small
bit of code I can show from the source:
If you stopped using malloc and free in a C++ application it would have been
even better. Rule number 1 in C++ : never ever use malloc and free,
especialy to allocate memory for C++ objects with constructor and
destructor !
That was exactly why I wanted to impress upon new game developers the
issue with doing such. Sadly, the malloc was an ancient remnant from
one of the very first iterations of the engine, and as such was in C,
rather than C++…as time evolved, the malloc code sadly did not.
And don’t forget that all “new []” pointers must be destroyed with “delete
[]” too.
That, like the issue about malloc and c++ objects using
constructors/destructors, goes without saying. Thanks for the interest
though, for a while I thought I was simply talking to myself. 
-Elden>> std::vector<p_Bubble> g_BubbleS(Count);
std::vector g_BubbleG(Count);
/* using the vectors /
…
/ cleaning up, removing surface, etc /
for (int i_Remove = 0; i_Remove < g_BubbleS.size(); i_Remove++) {
g_BubbleS[i_Remove].g_Remove(); };
/ etc */
This code is from the particle emitter that was creating the problem in
the application. Apparently the only thing keeping the application
running was a bit of allocated memory for the surface in each element, a
32x32 image. This is a really easy bug to overlook, and had my
development environment not balked at the idea of replacing a file that
was in use, I would still be unaware of the issue. Finding the issue
took approximately 9 hours, since there are literally thousands of lines
of code, and no error was thrown. I can only hope that this helps
someone else.
Remember, debugging is great…but ALWAYS test, test, test!
-Elden
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Elden Armbrust wrote:
Christophe Cavalaria wrote:
Elden Armbrust wrote:
Well, I found the problem. It was a matter of destructor not being
called when free() was called on a malloc’ed array. The issue was
solved by using vectors and explicitly calling the proper destruction
code in a loop. I feel I have to impress upon anyone new to
programming, and even those new to game programming, how important
debugging, profiling, and testing of an application is. Here’s a small
bit of code I can show from the source:
If you stopped using malloc and free in a C++ application it would have
been even better. Rule number 1 in C++ : never ever use malloc and free,
especialy to allocate memory for C++ objects with constructor and
destructor !
That was exactly why I wanted to impress upon new game developers the
issue with doing such. Sadly, the malloc was an ancient remnant from
one of the very first iterations of the engine, and as such was in C,
rather than C++…as time evolved, the malloc code sadly did not.
I’m sure you can find a good C++ book written by someone really smart you
can use to teach them some good manners 
Something like "Effective C++"
by Scott Meyers for example.
For the malloc code, it shouldn’t take more than a few hours with grep to
find and replace all occurences if (m|c|re)alloc and free.
Christophe Cavalaria wrote:
Elden Armbrust wrote:
Christophe Cavalaria wrote:
Elden Armbrust wrote:
Well, I found the problem. It was a matter of destructor not being
called when free() was called on a malloc’ed array. The issue was
solved by using vectors and explicitly calling the proper destruction
code in a loop. I feel I have to impress upon anyone new to
programming, and even those new to game programming, how important
debugging, profiling, and testing of an application is. Here’s a small
bit of code I can show from the source:
If you stopped using malloc and free in a C++ application it would have
been even better. Rule number 1 in C++ : never ever use malloc and free,
especialy to allocate memory for C++ objects with constructor and
destructor !
That was exactly why I wanted to impress upon new game developers the
issue with doing such. Sadly, the malloc was an ancient remnant from
one of the very first iterations of the engine, and as such was in C,
rather than C++…as time evolved, the malloc code sadly did not.
I’m sure you can find a good C++ book written by someone really smart you
can use to teach them some good manners Something like "Effective C++"
by Scott Meyers for example.
For the malloc code, it shouldn’t take more than a few hours with grep to
find and replace all occurences if (m|c|re)alloc and free.
grep and sed, of course. Luckily that “legacy” code was just part of
one of many class members, and the only one containing such archaic
methods for “dynamic” arrays. Luckily I don’t run into new programmers
and/or new game programmers too often, aside from the SDL irc channel
that is, so I don’t have to worry about recommending books too often. I
figured, “Well, I was willing to post the problem. I might as well post
the answer and a warning to others that might not even know about that
kind of problem…like the person that did it in my engines code.”
-Elden>_______________________________________________
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl