Opened 21 years ago
Closed 21 years ago
#1276 closed defect (fixed)
COMI: ScummVM crashes after difficulty selection screen
| Reported by: | eriktorbjorn | Owned by: | fingolfin |
|---|---|---|---|
| Priority: | normal | Component: | Engine: SCUMM |
| Version: | Keywords: | ||
| Cc: | Game: | Monkey Island 3 |
Description
With today's CVS snapshot, ScummVM crashes for me right after the difficulty selection screen i COMI. This happened both under Linux and Windows. Here's the backtrace from Windows:
Program received signal SIGSEGV, Segmentation fault. [Switching to thread 3316.0x6e0] 0x00000000 in ?? () (gdb) bt #0 0x00000000 in ?? () #1 0x005309eb in Timer::handler(int) (this=0x137aab0, t=10) at common/timer.cpp:96 #2 0x00530908 in Timer::timer_handler(int) (t=10) at common/timer.cpp:79 #3 0x1003474d in callback_wrapper (ms=10, param=0x5308e8) at SDL_timer.c:252 #4 0x1003442a in SDL_ThreadedTimerCheck () at SDL_timer.c:137 #5 0x1003410a in HandleAlarm (uID=16, uMsg=0, dwUser=0, dw1=0, dw2=0) at SDL_systimer.c:180 #6 0x76b42271 in _libwinmm_a_iname () #7 0x76b49e64 in _libwinmm_a_iname () #8 0x0296e850 in ?? () (gdb) Cannot access memory at address 0x50e58955
I don't have the time to look into this right now, but unless someone has already fixed it by then, I'll see if I can look into it tonight. (It's morning here now.)
Ticket imported from: #825331. Ticket imported from: bugs/1276.
Change History (2)
comment:1 by , 21 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
Problem was caused by the bundle music timer removing itself. This resets the timer entry, of course. And since we now may repeatedly invoke the timer procedures (to improve the timer resolution), this let to an endless loop.
I added a workaround for this. But on the long run, we should fix the whole bundle music timer business. Removing yourself isn't a good idea for a timer, and it might cause reentrency problems depending on how the backend implementes the timer mutex
Like, we try to lock the mutex a second time, albeit in the same thread. This can lead to a deadlock on some systems. And then we unlock the mutex two times; on system which don't count the number of times you lock the mutex (many systems don't do it), this means that we end up with a mutex which has been unlocked to early -> race condition potential!!!
As a consequence, the bundle music timer should be rewritten to avoid this. Once that happens, I'll make the Timer error out if a timer attempts to remove itself.