|
|
|
| d_list_proc freezing |
|
Elias
Member #358
May 2000
|
Yes, of course. Peter and Eric probably know a lot about it, judging from that recent [AD] posts about the timer locking.. -- |
|
Kitty Cat
Member #2,815
October 2002
 |
Quote: I guess fixing that should be one of the first things to do for 4.3 (and then backport it into 4.2.1 I guess). I'd suggest trying now. You never know if fixing it may break ABI compatibility. -- |
|
Elias
Member #358
May 2000
|
About the mouse bug.. I can't reproduce it (tried all versions in fullscreen, with and without TARGET_ARCH_EXCL). But I tried to track when SetCursor is called, and it is called suspiciously often. In fact, like 100 times a second while the cursor is moved (and only if it is moved). In wwnd.c, the WM_SETCURSOR message is received, which means mouse_set_syscursor in wmouse.c is called, which executes: SetCursor(_win_hcursor); /* Make sure the cursor is removed by the system. */ PostMessage(allegro_wnd, WM_MOUSEMOVE, 0, 0); No idea what _win_hcursor is. MSDN says: Quote: The WM_SETCURSOR message is sent to a window if the mouse causes the cursor to move within a window and mouse input is not captured. So, I'm somewhat puzzled why it is called so often, since I only moved it around inside the grabber window. [Edit] Quote: I have fiddled with the Allegro code and it seems to be crashing on a function called SetCursor in "src/win/wddraw.c." If I comment out the line SetCursor(NULL); (line 484 of wddraw.c) the crashing problem is gone. According to gdb, that is only called once in the beginning.. so I wonder how it could fix it.. -- |
|
Evert
Member #794
November 2000
 |
Quote: No idea what _win_hcursor is. It's the HCURSOR corresponding to the mouse bitmap. In other words, it's the Windows handle to the hardware cursor image (either custom or system). |
|
Elias
Member #358
May 2000
|
Well, I tried to comment it out, and it simply makes the cursor disappear. So _win_hcursor must be some sort of invisible cursor (and it has to be re-set after every mouse movement for some reason). -- |
|
Evert
Member #794
November 2000
|
Quote: _win_hcursor must be some sort of invisible cursor It can be, if it is NULL it is treated as an invisible cursor. It's function is what I outlined above. Quote: (and it has to be re-set after every mouse movement for some reason). This does sound peculiar though... |
|
Elias
Member #358
May 2000
|
Yes, so quite probably there's a way to tell a window to use a certain cursor in a way it remembers. But probably it has nothing to do with the original problem. In any case, I could not reproduce the grabber problem here, nor the crash-on-shutdown problem. -- |
|
Evert
Member #794
November 2000
|
Windows should remember that the cursor was set; it wouldn't make sense that you need to reset the cursor all the time. EDIT: about not being able to reproduce the bug, I think the original report was for a HyperThreading machine, which is more sensitive to threading bugs than a normal single-processor computer. You probably need a HT machine to debug this effectively. |
|
Elias
Member #358
May 2000
|
Hm, mine has HT - that is, at least in linux (how do you think I could detect the x11 async replies? In windows.. I'm not really sure. Is there a way to check if it is used by windows? I believe ever since I followed the instructions to get some old win98 game working, it is half broken (the shutdown button stopped working.. and probably HT and other things are disabled). -- |
|
Todd Cope
Member #998
November 2000
 |
Quote: Quote: According to gdb, that is only called once in the beginning.. so I wonder how it could fix it.. I can say that it is being called every time scare_mouse_area is called, which happens when the draw message is sent to the dialog object. To verify that it is called I added the line clear_bitmap(screen) directly above SetCursor(NULL). Every time something goes to be redrawn the screen is cleared. This doesn't happen in windowed mode, though, so that could be why you are not seeing it with GDB. |
|
Evert
Member #794
November 2000
|
Quote: how do you think I could detect the x11 async replies?
Heh. Quote: In windows.. I'm not really sure. Is there a way to check if it is used by windows?
I think Windows reports two processors instead of one, same as Linux. EDIT: Quote: SetCursor(NULL). Every time something goes to be redrawn the screen is cleared. This doesn't happen in windowed mode, though, so that could be why you are not seeing it with GDB.
The hardware cursor code shouldn't be called at all if you're in fullscreen mode (Windows can't do hardware cursors in fullscreen mode)... so checking for that should make the problem go away. EDIT2: |
|
Todd Cope
Member #998
November 2000
|
Crashes more frequently with the patch. |
|
Evert
Member #794
November 2000
|
Huh?! |
|
Todd Cope
Member #998
November 2000
|
I haven't had time to look at it yet. Edit: Okay, I'm looking into it now, I will write back here what I find out. Edit 2: I solved the problem. In mouse.c freeze_mouse_flag was being reset before show_mouse(NULL) so the timer thread could be updating the mouse while show_mouse(NULL) was erasing it. Attached is a patch that fixes the problem. |
|
Elias
Member #358
May 2000
|
Todd Cope said: Edit 2: I solved the problem. In mouse.c freeze_mouse_flag was being reset before show_mouse(NULL) so the timer thread could be updating the mouse while show_mouse(NULL) was erasing it. Attached is a patch that fixes the problem. Great! This may also fix some other bugs reported in the past.. (oh, btw, with all the talk about the forum usability.. why wasn't the yellow bulb turned on for this thread? I only found this cause I wanted to reply anyway..) Evert said: I assume you don't want to reinstall Windows for this, right? No, wasn't necessary - but it was hidden even worse than your description.. anyway, the good news is, I enabled HT again, and it allowed me to finally reproduce the freeze-on-exit bug. Just sent a patch to fix it to [AD] (fixes it for me at least). So this means, in beta3, the GUI mouse, as well as the windows timers, should be more stable -- |
|
Todd Cope
Member #998
November 2000
|
I forgot to update scare_mouse() so I went ahead and fixed that, too. It wasn't even freezing the mouse before eresing it. I've attached the new patch. Quote: (oh, btw, with all the talk about the forum usability.. why wasn't the yellow bulb turned on for this thread? I only found this cause I wanted to reply anyway..) I think editing a post doesn't light up the bubble because people could abuse that and use it to bump their thread to the top. |
|
Elias
Member #358
May 2000
|
I must admit, I don't know anything about mouse_freeze_flag. But looking at the patch, it seems like it is safe to apply in any case. If you want, feel free to explain what it does in detail, and how it prevents the crash.. -- |
|
Todd Cope
Member #998
November 2000
|
Okay, the mouse_freeze_flag, to me, appeared to be in place so that you could prevent the mouse from drawing from the timer thread if you needed to. Looking at the show_mouse() function I didn't see anything that would prevent the timer thread from updating the mouse while show_mouse() was being executed. I then looked at scare_mouse_area() to see if it had taken any steps to prevent the mouse from updating and indeed it set the mouse_freeze_flag to TRUE. But I noticed that it was being set back to false before the mouse was even being erased so I simply moved the line that reset the mouse_freeze_flag from directly above show_mouse(NULL) to directly below it and problem solved. After I posted the patch last night I realized I hadn't looked at scare_mouse() so today I checked it and it wasn't even freezing the mouse at all. I simply edited scare_mouse() to mimic scare_mouse_area() in the way it freezes the mouse. Something else to note, I had already installed Evert's patch as well. It may or may not be needed to stop the crashing problem I was having but I think his patch addresses other problems with the Windows-specific mouse code. |
|
Elias
Member #358
May 2000
|
Quote: Okay, the mouse_freeze_flag, to me, appeared to be in place so that you could prevent the mouse from drawing from the timer thread if you needed to. Looking at the show_mouse() function I didn't see anything that would prevent the timer thread from updating the mouse while show_mouse() was being executed. Hm, true, since the timer mutexes were disabled. The patch I send to [AD] today fixes that though.. so maybe with that, the mouse_freeze_flag isn't even needed anymore. -- |
|
Todd Cope
Member #998
November 2000
|
I don't know a thing about threading, but I do know that freezing the mouse stopped the crashing problem I was having completely. I guess my ignorance helped me to figure out a different (albeit improper) way of fixing the problem |
|
Elias
Member #358
May 2000
|
Are you subscribed to [AD]? Else, you find the patch here: http://sourceforge.net/mailarchive/message.php?msg_id=11596396 And I didn't look yet if if would solve the mouse problem. I guess, timer callbacks (including the mouse drawed) aren't locked by default, so then the freeze solution sounds like a good way. -- |
|
Todd Cope
Member #998
November 2000
|
I applied your patch, seems to fix the freezing problem at allegro_exit(). I went through a bunch of the example programs and they all exited flawlessly. |
|
Evert
Member #794
November 2000
|
Please check that freeze_mouse_flag does what the docs say it does. As far as I know it does, but if you've seen something in the code that you think is wrong, then by all means submit a patch for it! In any case, good work! |
|
Todd Cope
Member #998
November 2000
|
The mouse is redrawn by mouse_move() and it checks if mouse_freeze_flag is TRUE before trying to draw. It is not used for anything else in Allegro. |
|
Elias
Member #358
May 2000
|
With the timer patch, but without the freeze_flag changes - does it still crash? -- |
|
|
|
.
