[SDL] Random crashes inside an SDL_Thread

[benang at cs.its.ac.id]

Thanks for replying. Okay, I'll elaborate more.
Ulrich Eckhardt said:
> On Monday 07 May 2007 04:48:40 benang at cs.its.ac.id wrote:
>> void CMainApp::createTempLatex()
>> {
>>   fstream filestr;
>>   filestr.open ("./temp-print.tex", fstream::out);
>
> The 'out' is declared in std::ios_base in fact and only inherited here. If
> you
> used std::ofstream, you could save yourself the hassle of it.
>

Well, it's just because the first think I had in mind is fstream, not
ofstream. I could propably change it anyway.


>>   fstream<<"\\begin{document}"<<endl;
>>   .....  //The body of the LaTeX file
>>   fstream<<"\\end{document}"<<endl;
>>   filestr.close();
>
> What, no error handling? Flush the stream and then check its streamstate.
> If
> its failbit or badbit are set, throw an appropriate exception. Also, I
> would
> have done the same after open(), because that one is most likely to fail.
> BTW: If the rest of your app is like that, you have a lot of work to do!
>

Well, there are actually some error handling but I didn't include it here
because it's actually working and didn't have any error.

>> void CMainApp::createTempPostScript()
>> {
>>     system("latex temp-print.tex -halt-on-error");
>>     system("dvips temp-print -Pcmz -t landscape -o temp-print.ps");
>> }
>
> Even system() returns something, though I'm not sure if it's the
> returnvalue
> of the called process. You might have to use some platform-specific hack
> to
> get to it.
>

Yeah, this one is actually kind of dangerous. I didn't add some error
handling because I don't know whether system returned any value or not.
I'll consult the manual again. I have the suspicion that these system
calls are the one causing it all. FYI, latex and dvips showed their
verbose on the console screen and occasionally (not always) they showed
that they needed to do some extra work to make a font file. And because of
this extra work, the timeout for printing was reached even if the system
calls has not been completed yet. And thus the application killed the
thread prematurely. Also I don't know what is the behaviour of SDL_Thread
if it has a system call in it. I used the SDL_WaitThread() to wait for
that thread to finish. But I guess it always assumes that the thread was
finished even if its system calls are not. I know this because when I look
at the console, the verbose of latex or dvips didn't show completely (like
something suddenly kills the latex or dvips process).

>> And the printPostScriptFile() is for sending the PS file to the CUPS
>> spooling queue for printing.
>>
>> I don't know what's wrong with it but this thread function randomly
>> generates crashes.
>
> Where? Look at the backtrace in a debugger! Does it access any shared
> resources?
>

Well it's just my assumption. I haven't managed to backtrace it partly
because it's so random that I couldn't reproduce it properly. And also
when it freezes, the whole X windows freezes also. So I have to just kill
X windows (along with the application and gdb) manually from the terminal.

>> Often it worked fine until few printing. But every now
>> and then it will crash. And the crash is always in this printing
>> routine.
>> The crash itself is not always a segmentation error. This is what
>> usually
>> happen if the application crashed:
>> 1. Back to terminal with segmentation error
>> 2. Hangs up. The animation and progress bar are not working. The event
>> handler also not working. It's like the system freezes out.
>> 3. Infinite loop. The event handler, animation, and progress bar are
>> working. But because the application needed the thread to finish before
>> going to the next state, it will stay inside the current state (printing
>> state). This always happens if the thread is still doing its stuffs in
>> one
>> of the system calls yet SDL_WaitThread() has been called.
>>
>> Can anybody give me some help here? How do you usually solve this kind
>> of
>> problem? Thanks in advance.
>
> Impossible to help here. There could be any numer of things going wrong
> here
> and without some relevant information nobody will be able to help you.
> Also,
> if you can, provide a minimal(!) example - yours isn't, it's too small,
> i.e.
> incomplete.
>

Well, the whole code is too large and I don't know what compensate
"relevant code". I just point out the functions that I know was being
executed when it crashed. It always crash at this point although the crash
itself is random.

> Uli
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>


Fare thee well,
Bawenang R. P. P.

----------------
ERROR: Brain not found. Please insert a new brain!

“Do nothing which is of no use.” - Miyamoto Musashi.

"I live for my dream. And my dream is to live my life to the fullest."