d_list_proc freezing

d_list_proc freezing

Todd Cope

Member #998

November 2000

There seems to be a problem with d_list_proc(). When I'm using the grabber if I am scrolling through the data list using the scroll bar the program crashes occasionally. 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.

I could only make this problem happen in fullscreen modes but I reproduced it in the demo game as well on the mode selector screen. I haven't been able to get it to happen outside the GUI routines so it may just be a problem with something in d_list_proc(). I am still looking into the problem but I just wanted to know if anyone else has had this problem too.

Kitty Cat

Member #2,815

October 2002

What version of Windows? What version of Allegro?

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Todd Cope

Member #998

November 2000

Oops, sorry, forgot to specify.

WinXP Home SP2
Allegro 4.2b2

Kitty Cat

Member #2,815

October 2002

Does it crash or just freeze up? Can you get a backtrace?

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Todd Cope

Member #998

November 2000

I think it is crashing, it freezes for a few seconds and then crashes. I don't know how to do a backtrace.

Kitty Cat

Member #2,815

October 2002

First step would be to build the debug Allegro lib (make DEBUGMODE=1 and make DEBUGMODE=1 install). Second would be to make sure the program uses windowed mode. Then run it in GDB (assuming you're using MinGW). When it freezes/crashes, type 'info threads' and 'bt' in gdb.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

Todd Cope

Member #998

November 2000

I can do all that, the only problem is the crashing problem only happens in fullscreen mode.

Kitty Cat

Member #2,815

October 2002

You can't really use gdb in fullscreen. When the app crashes, gdb will freeze it, and you can't really switch away with alt-tab or anything.

--
"Do not meddle in the affairs of cats, for they are subtle and will pee on your computer." -- Bruce Graham

ReyBrujo

Moderator

January 2001

I was not able to reproduce it. Maybe the fact I was using the static linked version of the demo has something to do, no idea...

--
RB
光子「あたしただ…奪う側に回ろうと思っただけよ」
Mitsuko's last words, Battle Royale

Todd Cope

Member #998

November 2000

I can make it happen by holding the mouse button on the slider and moving up and down with the mouse until it crashes. Usually happens pretty quick. Not really much else I can do right now, I'll look at it some more tomorrow.

Evert

Member #794

November 2000

Quote:

I have fiddled with the Allegro code and it seems to be crashing on a function called SetCursor in "src/win/wddraw.c." [...] problem is the crashing problem only happens in fullscreen mode.

I have no idea, but this is strange: SetCursor should not be used in fullscreen mode, since Windows does not do any cursor drawing in fullscreen mode. Can you check the code in wddraw.c and add if (is_windowed_mode()) to the SetMouse calls to disable them in fullscreen, if these checks aren't there already?

Elias

Member #358

May 2000

Hm, grabber doesn't even use hardware cursors.. so only the initialization code should call a function with SetCursor in it.

Does the attached patch fix the problem? It simply adds checks for the HW cursor before modifying hw_cursor_dirty, which in turn could trigger the HW cursor to be displayed inside show_mouse..

--
"Either help out or stop whining" - Evert

Evert

Member #794

November 2000

I'm not sure that's the problem. The mouse cursor vtable functions shouldn't be used or active in Windows in fullscreen modes. However, I think the Windows port uses the same vtable for DirectX windowed and fullscreen modes.
Either we should manually set those entries to NULL in fullscreen mode and restore them in fullscreen mode (probably the second best solution, the best being to have seperate vtables for fullscreen and windowed mode), or check for fullscreen/windowed mode explicitly in the mouse cursor functions.

Elias

Member #358

May 2000

But what if you are in windowed mode? Then you still don't want hw_cursor_dirty to be set, while no HW cursor is available, right? Or should that be covered by the other checks already?

--
"Either help out or stop whining" - Evert

Evert

Member #794

November 2000

Quote:

Then you still don't want hw_cursor_dirty to be set, while no HW cursor is available, right?

You do, because it may become available. Remember that (with the current implementation at least) you cannot know for sure if it will work or not until you actually try to set it.

Quote:

Or should that be covered by the other checks already?

I think it should be. At any rate, the hw_cursor_dirty flag is intended to indicate that the hardware cursor needs to be reset if it is in use. It should be ignored if no hardware cursor is in use or can be set.

Elias

Member #358

May 2000

Ah, ok. I was mainly thinking of this:

      /* Custom hardware cursor? */
      if (hw_cursor_dirty) {
   got_hw_cursor = FALSE;

   if ((gfx_driver) && (gfx_driver->set_mouse_sprite) && (!_dispsw_status))
      if (gfx_driver->set_mouse_sprite(mouse_sprite, mouse_x_focus, mouse_y_focus) == 0)
         got_hw_cursor = TRUE;

   hw_cursor_dirty = FALSE;
      }

It will call gfx_driver->set_mouse_sprite, no matter if a HW cursor is currently enabled or not (if I don't miss something else).

--
"Either help out or stop whining" - Evert

Evert

Member #794

November 2000

That's what it should do, because it's possible that gfx_driver->set_mouse_sprite can set a hardware cursor even if one isn't in use now. The only problem would be if the hardware cursor is disallowed by disable_hardware_cursor()... that should probably be checked in that if statement, unless the gfx_driver entries are responsible for that.
I'm not now sure how I designed it, but it may very well be the latter. I don't think the Windows port bothers, which is probably a bug. If the X11 port vtable entries do check it, then it's certainly a bug.

EDIT: it's a bug in the Windows port. The X11 port does check if the hardware cursor is enabled before trying to show and use it. That said, I'm not sure why you can't call SetCursor in fullscreen mode in Windows... on my system at least, it just didn't do anything.
Probably a good idea to make it explicitly do nothing though, instead of relying on Windows to ignore it. The reason I didn't do this is for the off chance that some day Windows aill support this through the same API it uses at the moment, in which case it would work automagically in Allegro.

Todd Cope

Member #998

November 2000

I can't reproduce the bug outside of the context of d_list_proc() so maybe it's just a bug with d_list_proc(). I edited guiproc.c so that the list box would update randomly (meaning it would redraw at random intervals) instead of based on whether or not the list had scrolled and it wouldn't crash except when I would move the mouse and cause the list to scroll.

Elias

Member #358

May 2000

Well, without a backtrace, we probably won't find out the exact circumstances of the crash. And since it only happens in fullscreen..

Let's hope checking for HW cursor availability before calling SetCursor will fix it.

--
"Either help out or stop whining" - Evert

Todd Cope

Member #998

November 2000

Nevermind about the last post, it's not d_list_proc(). I played with it some more and made it so you could scroll the list using the keyboard while holding the mouse button. It only crashes when the mouse is moving and the list is scrolling. I edited it again and made it so the list redraws every time and it crashes when the list isn't scrolling. It only crashes when the mouse is being moved while SetCursor(NULL) (a la scare_mouse_area) is being called.

Evert

Member #794

November 2000

Quote:

It only crashes when the mouse is being moved while SetCursor(NULL) is being called.

Aha! 't Is a threading issue!

Unfortunately I don't know how the Windows port handles thread locking...

Todd Cope

Member #998

November 2000

I thought it might be after messing with it but I can't decipher how the input thread works yet.

Edit: I searched through the Allegro sources and found methods for mutex locking and unlocking but these are only used in the sound mixing routines and the timer routines. I don't know anything about threading so mutex locking might not be what you're talking about but if it is then it's not used in the input thread at all.

Edit 2: I thought I should also mention another problem I've been having with Allegro since these two problems are related now. Allegro randomly freezes on shutdown. This is probably another threading issue. I never had these problems before I got my new computer but this computer has Hyper Threading so that could be why these problems are showing up now.

Evert

Member #794

November 2000

Mutex locking is indeed what you're locking for. I'm not sure what you would have to lock though... I'm guessing the timer thread (since that is where Allegro does its mouse updating), but I'm not sure.

Quote:

This is probably another threading issue.

Yup.

Quote:

I never had these problems before I got my new computer but this computer has Hyper Threading so that could be why these problems are showing up now.

Threading issues and race conditions tend to show up much sooner on a Hyper Threading or dual processor machine. Unfortunately, I don't have access to one that runs Windows, so I can't look into this myself... the UNIX port seems to work fine now with multi-processor machines though.

Elias

Member #358

May 2000

Quote:

Unfortunately I don't know how the Windows port handles thread locking...

From what I understand, it has some flaws (e.g. the commented out ALLEGRO_MULTI_THREADED for the windows port, so some parts simply lack locking).. 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).

--
"Either help out or stop whining" - Evert

Evert

Member #794

November 2000

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).

Absolutely, if we don't have a patch (for the current issue) before 4.2.0 comes out.
Rewriting the Windows threading code is a bit too much at this point... :-/