From: Matthias G. <mat...@ps...> - 2005-02-21 18:17:39
Attachments:
matthias.gondan.vcf
|
Dear Allegro people, In the archive I have read some discussions of allegro programs not exiting cleanly. I also have this problem and I was wondering if others have that too. WindowsXP, MinGW-gcc 3.4.2, Msys, Allegro-4.1.18, compiling with "fix.sh, make MINGDIR=/mingw and make install MINGDIR=/mingw" I did some small changes to exaccel.c to reproduce it, because it is appearing in only 10% of the calls to the program (see end of this Email). Basically, I added a counter: after 300 loops (ca. 1s), the program exits automatically and prints "last call". The new exaccel.exe is called by a shell script from MSYS: echo calling exaccel ./exaccel echo calling exaccel ./exaccel echo calling exaccel ./exaccel (and so on...). Now to the bug: Every 5th to 10th time, exaccel does not return properly: After the screen with the white mice is shut down, the windows background reappears and a small icon is displayed in the taskbar. Clicking onto the icon or onto another window does not help, the only possibility is to press Ctrl+C in the MSYS window. Did others encounter that problem, too? Any hints to solve this issue/work around it would be greatly appreciated. Best wishes, Matthias diff exaccel.c exaccel.old 17c17 < #include <stdio.h> --- > 71c71 < int i, ii; --- > int i; 117,119c117 < ii=0 ; < while (!done && ii<300) { < ii++ ; --- > while (!done) { 187,188d184 < fprintf(stdout, "last call\n") ; < fflush(stdout) ; |
From: Lennart P. <len...@ya...> - 2005-02-21 19:21:07
|
Hi, I have this problem too, using WinXP SP2 and MSVC 6.0 with Allegro 4.0.3. It's just sometimes that the programm won't exit and leave a process that has about 400k of memory but doesn't use any processor time. I noticed that this happens more often using the debug library (alld.lib) than with the normal library (alleg.lib). Greetings, Master Lenman ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de |
From: Matthias G. <mat...@gm...> - 2005-02-22 13:58:57
|
Dear Allegro people, I think I have found at least a workaround for that problem. After some "debugging", I solved the problem by changing wtimer.c as following /* tim_win32_exit: * Shuts down either timer driver. */ #include <stdio.h> static void tim_win32_exit(void) { DWORD ret ; // added // ... /* wait until thread has ended */ // was: WaitForSingleObject(timer_thread, INFINITE); ret = WaitForSingleObject(timer_thread, 1000); if(ret == WAIT_TIMEOUT) // occurs sometimes { fprintf(stderr, "tim_win32_exit WAIT_TIMEOUT\n") ; fflush(stderr) ; } // if if(ret == WAIT_FAILED) // occurs sometimes { fprintf(stderr, "tim_win32_exit WAIT_FAILED\n") ; fflush(stderr) ; } // if if(ret == WAIT_OBJECT_0) // occurs in the majority of times { fprintf(stderr, "tim_win32_exit WAIT_OBJECT_0\n") ; fflush(stderr) ; } // if if(ret == WAIT_ABANDONED) // never occurs { fprintf(stderr, "tim_win32_exit WAIT_ABANDONED\n") ; fflush(stderr) ; } // if and so on Perhaps one of the developers could comment this, because I have no clue what is happening here and why the timer thread seems to hang. Best wishes, Matthias Lennart P. wrote: >Hi, >I have this problem too, using WinXP SP2 and MSVC 6.0 >with Allegro 4.0.3. >It's just sometimes that the programm won't exit and >leave a process that has about 400k of memory but >doesn't use any processor time. I noticed that this >happens more often using the debug library (alld.lib) >than with the normal library (alleg.lib). > >Greetings, >Master Lenman > > > > > > >___________________________________________________________ >Gesendet von Yahoo! Mail - Jetzt mit 250MB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de > > >------------------------------------------------------- >SF email is sponsored by - The IT Product Guide >Read honest & candid reviews on hundreds of IT Products from real users. >Discover which products truly live up to the hype. Start reading now. >http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > |
From: AJ <aj...@vi...> - 2005-02-22 14:43:23
|
something is keeping the object and not releasing it. check all the other WaitForSingleObjects() and follow the path for each func.. are there exit points for each entry point ? Matthias Gondan wrote: > Dear Allegro people, > > I think I have found at least a workaround for that problem. After some > "debugging", I solved the problem by changing wtimer.c as following > > /* tim_win32_exit: > * Shuts down either timer driver. > */ > #include <stdio.h> > > static void tim_win32_exit(void) > { > DWORD ret ; // added > // ... > > /* wait until thread has ended */ > // was: WaitForSingleObject(timer_thread, INFINITE); > ret = WaitForSingleObject(timer_thread, 1000); > if(ret == WAIT_TIMEOUT) // occurs sometimes > { > fprintf(stderr, "tim_win32_exit WAIT_TIMEOUT\n") ; > fflush(stderr) ; > } // if > > if(ret == WAIT_FAILED) // occurs sometimes > { > fprintf(stderr, "tim_win32_exit WAIT_FAILED\n") ; > fflush(stderr) ; > } // if > > if(ret == WAIT_OBJECT_0) // occurs in the majority of times > { > fprintf(stderr, "tim_win32_exit WAIT_OBJECT_0\n") ; > fflush(stderr) ; > } // if > > if(ret == WAIT_ABANDONED) // never occurs > { > fprintf(stderr, "tim_win32_exit WAIT_ABANDONED\n") ; > fflush(stderr) ; > } // if > > and so on > > > Perhaps one of the developers could comment this, because I have no > clue what > is happening here and why the timer thread seems to hang. > > Best wishes, > > Matthias > > > Lennart P. wrote: > >> Hi, >> I have this problem too, using WinXP SP2 and MSVC 6.0 >> with Allegro 4.0.3. >> It's just sometimes that the programm won't exit and >> leave a process that has about 400k of memory but >> doesn't use any processor time. I noticed that this >> happens more often using the debug library (alld.lib) >> than with the normal library (alleg.lib). >> >> Greetings, >> Master Lenman > |
From: Matthias G. <mat...@gm...> - 2005-02-22 17:47:15
|
Dear AJ, I don't understand a word. "follow the path for each func". But I have news: The problem can be worked around without touching allegro by calling remove_timer() before the program's end. To be more precise: before allegro shuts down the "graphics mode". In most cases, this is the end of the main program. tail of exaccel.c destroy_bitmap(image); destroy_bitmap(vimage); destroy_bitmap(page[0]); destroy_bitmap(page[1]); remove_timer() ; // allegro_exit() ; return 0; } END_OF_MAIN() Best wishes, Matthias AJ wrote: > > something is keeping the object and not releasing it. > check all the other WaitForSingleObjects() and follow the path for > each func.. are there exit points for each entry point ? > > > > > > Matthias Gondan wrote: > >> Dear Allegro people, >> >> I think I have found at least a workaround for that problem. After some >> "debugging", I solved the problem by changing wtimer.c as following >> >> /* tim_win32_exit: >> * Shuts down either timer driver. >> */ >> #include <stdio.h> >> >> static void tim_win32_exit(void) >> { >> DWORD ret ; // added >> // ... >> >> /* wait until thread has ended */ >> // was: WaitForSingleObject(timer_thread, INFINITE); >> ret = WaitForSingleObject(timer_thread, 1000); >> if(ret == WAIT_TIMEOUT) // occurs sometimes >> { >> fprintf(stderr, "tim_win32_exit WAIT_TIMEOUT\n") ; >> fflush(stderr) ; >> } // if >> >> if(ret == WAIT_FAILED) // occurs sometimes >> { >> fprintf(stderr, "tim_win32_exit WAIT_FAILED\n") ; >> fflush(stderr) ; >> } // if >> >> if(ret == WAIT_OBJECT_0) // occurs in the majority of times >> { >> fprintf(stderr, "tim_win32_exit WAIT_OBJECT_0\n") ; >> fflush(stderr) ; >> } // if >> >> if(ret == WAIT_ABANDONED) // never occurs >> { >> fprintf(stderr, "tim_win32_exit WAIT_ABANDONED\n") ; >> fflush(stderr) ; >> } // if >> >> and so on >> >> >> Perhaps one of the developers could comment this, because I have no >> clue what >> is happening here and why the timer thread seems to hang. >> >> Best wishes, >> >> Matthias > |
From: Elias P. <el...@us...> - 2005-02-22 18:39:21
|
On Tue, 2005-02-22 at 18:47 +0100, Matthias Gondan wrote: > But I have news: The problem can be worked around without touching > allegro by > calling remove_timer() before the program's end. To be more precise: before > allegro shuts down the "graphics mode". In most cases, this is the end > of the > main program. > Hm, interesting. allegro_exit already removes the timer, just possibly after it shuts down the gfx mode. Can you try putting the calls to install_timer/install_keyboard and so on after set_gfx_mode, in your modified exaccel.c, and see if the problem also is solved by that? (without the added remove_timer at the end) About the WaitForSingleObject in tim_win32_exit - as I understand the code, it simply should wait until the timer_thread dies. The timer thread is signalled with the timer_stop_event in the line before. The timer thread (tim_win32_high_perf_thread) is an endless loop, which tests for that even and exits when it is encountered: /* wait calculated time */ result = WaitForSingleObject(timer_stop_event, TIMER_TO_MSEC(delay)); if (result != WAIT_TIMEOUT) { thread_exit(); return; } Now, the question we need answered - what is happening there? Either: 1. that point is never reached, since the previous line: delay = _handle_timer_tick(COUNTER_TO_TIMER(diff_counter.QuadPart)); never returns due to a deadlock. 2. WaitForSingleObject never returns WAIT_TIMEOUT, since e.g. delay is too long, or some other reason. 3. thread_exit actually is called, and the idea behind the code is flawed I think 2. and 3. are quite unlikely, and 3. can be tested with a simple printf. So probably it's 1. - there's a deadlock inside one of the timer callbacks. Now a debugger would tell use exactly where. I'll try your modified exaccel in windows when I get a chance (which could be in a long time), and hopefully I can reproduce it (last time I tried I couldn't, but didn't have your modified exaccel) and run in gdb. Or if you want, you can play around with gdb :) Just break the program manually when it is deadlocked, switch to the timer thread, and see where in the source code it is locked. -- Elias Pschernig |
From: Matthias G. <mat...@gm...> - 2005-02-23 16:54:17
|
I tried. Ironically, the bug seems to have disappeared at the moment. I will continue to search for it. >Hm, interesting. allegro_exit already removes the timer, just possibly >after it shuts down the gfx mode. > >Can you try putting the calls to install_timer/install_keyboard and so >on after set_gfx_mode, in your modified exaccel.c, and see if the >problem also is solved by that? (without the added remove_timer at the >end) > > |