August 2005 - Wine-Devel - list.winehq.org

Re: Help with debugging needed

by James Liggett

On Thu, 2005-08-11 at 21:39 +0000, Stefan Dösinger wrote: > Hello, > I am trying(once again) to get Empire Earth [1] running with wine. After > solving a few problems[2], I've run into a strange access violation crash. It > looks like a buffer overrun, followed by a return to an invalid adress. > > A +relay,+snoop trace gives this: > ... > 0009:CALL Low-Level Engine.?Deactivate(a)GERasterizer@@UAEJXZ() ret=7e2b9a14 > 0009:CALL Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() > ret=7e2bd6c5 > 0009:RET Low-Level Engine.?Dereference(a)UReferenceCounter@@QAEXXZ() > retval=7f24fa70 ret=7e2bd6c5 > 0009:Call ntdll.RtlEnterCriticalSection(7f074a40) ret=7f0294c5 > 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=7f0294c5 > 0009:Call ntdll.RtlLeaveCriticalSection(7f074a40) ret=7f029506 > 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=7f029506 > 0009:CALL MSVCRT._except_handler3(<unknown, check return>) ret=7beb649b > 0009:CALL MSVCRT._XcptFilter(<unknown, check return>) ret=00665947 > 0009:Call kernel32.GetLastError() ret=7800385f > 0009:Ret kernel32.GetLastError() retval=000005b4 ret=7800385f > 0009:Call kernel32.TlsGetValue(00000000) ret=7800386d > 0009:Ret kernel32.TlsGetValue() retval=7f180f80 ret=7800386d > 0009:Call kernel32.SetLastError(000005b4) ret=7800387e > 0009:Ret kernel32.SetLastError() retval=000005b4 ret=7800387e > 0009:Call kernel32.UnhandledExceptionFilter(7fc2f81c) ret=7800ed71 > 0009:Call > ntdll.NtQueryVirtualMemory(ffffffff,9803a11c,00000000,7fc2f6e8,0000001c,7fc2f6a8) > ret=7fd1aae1 > 0009:Ret ntdll.NtQueryVirtualMemory() retval=00000000 ret=7fd1aae1 > 0009:Call kernel32.IsBadCodePtr(7800add3) ret=22d2b743 > 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=22d2b743 > 0009:Call ntdll.NtCreateEvent(7fc2f6e8,001f0003,7fc2f6ec,00000001,00000000) > ret=7fccb9b9 > 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=7fccb9b9 > wine: Unhandled exception (thread 0009), starting debugger... > ... > > The crash messages look a little bit different every time, with illegal > instructions / access violations or even a Segmentation Fault without > starting winedbg at various addreses(Attached file crashes). On very rare > occasions, this crash doesn't occur, and the game continues to load and > crashes later in some ddraw function. Instead of crashing it complains about > a corrupted heap: > err:heap:HEAP_ValidateInUseArena Heap 0x7fd80000: prev arena 0x7fe01640 is I've also seen similar problems with related heap functions in WinMM. I'm told that there's something wrong with the heap manager library Wine uses. > not prev for in-use 0x7fe01cb0 > I've looked at a +heap trace, but I couldn't find anything usefull. > (See ee-nocrash for a log). I've also attached a normal log without any > special debug flags set(ee-normal.log.gz). I've added a few ERR statements > for testing in some functions. > > So my questions are: > *Am I right with my suspection that the problems are caused by a incorrect > return? It's possible. I'm working on a problem like that with palm desktop. But you won't know until you debug it :) It could be nasty to fix though. > *How can I get a disassembly of Low-Level > Engine.?Deactivate(a)GERasterizer@@UAEJXZ or simmilar functions. I didn't find > this symbol. If I had to guess, I'd say these functions are in the game itself, most likely in one or more DLLs. Your best bet here is to use a good disassembler. My personal favorite is IDA. You can find a demo version here: http://www.datarescue.be/downloaddemo.htm. This version works just fine for this sort of thing. > > Thanks for your help, > Stefan Dösinger > > [1] > A demo is available at > http://www.vugames.de/scripts/download.aspx?content=4&id=53721&nf=21&url=ft…, > but I haven't checked wheter it produces the same results. > > [2] > Other users reported a msvc runtime error, apparently caused by an error > returned by Main_DirectDraw_SetCooperativeLevel. EE calls this function with > cooplevel == DDSCL_SETFOCUSWINDOW. I made the function simply return DD_OK in > this case. > Furthermore it checks for sound support and the OS version(setting it to Win98 > or WinME is recommended) and it needs native msvcrt(It even seems to ship > it's own version) I've had a few programs with this behavior. Programs ship with copies of this library to make sure that it's available, since they can't assume that it'll be there. Normally I stick with native msvcrt in pretty much all cases. I hope this advice helps. Good Hunting ;-) James

Aug. 11, 2005

WINEALSA: comment on unexpected shrinking of mmap-buffer (resend)

by Alex Villacís Lasso

Alex Villacís Lasso wrote: > >> The good news: the patch sort of works (in my setup, at least, with >> Fedora Core 4). All the games I have (Japanese RPGs) now have smooth >> sound, unless the CPU load is too high. >> The bad news: the patch does nothing to make the dsound tests pass in >> Wine (but they were already failing before the patch :-) > > > In a previous post, I commented about DirectSound tests failing when > ALSA is used with full hardware acceleration. Now I know the reason why. > > As far as I can glean from the code, DirectSound is supposed to report > the application several properties of the sound system, including the > size of the hardware buffer. This hardware buffer is queried by the > snd_hw_params_get_buffer_size(), and is then converted from frame > units to bytes. Then the application, or in this case, the test, > expects the buffer size to remain constant for each and every hardware > buffer created, regardless of requested format. Only this assertion > fails in ALSA. For example, the capability query causes the following > output to be shown: > > trace:wave:DSDB_CreateMMAP format=U8 frames=11025 channels=2 > bits_per_sample=8 bits_per_frame=16 > trace:wave:DSDB_CreateMMAP created mmap buffer of 11025 frames (22050 > bytes) at 0x7c0fd100 > > This reported size (22050 bytes) remains constant as long as the > request is for U8 format with 2 channels (although the mmap address > jumps between three different values in my setup; this may or may not > be relevant). However, as soon as the requested format changes, the > trace shows the following: > > trace:wave:DSDB_CreateMMAP format=S16_LE frames=3763 channels=2 > bits_per_sample=16 bits_per_frame=32 > trace:wave:DSDB_CreateMMAP created mmap buffer of 3763 frames (15052 > bytes) at 0x7c0fd6b8 > > There goes a fourth mmap address, but the truly interesting thing is > that the buffer size also changes, and no longer matches the > previously reported size of 22050 bytes. The test then goes and plays > a 5-second sound with the (now incorrect) buffer size of 22050 bytes, > not noting that the reported position is wrapping around at 15052 bytes: > > ds3d.c:431: Playing 5 second 440Hz tone at 11025x16x2 > > ... > > trace:dsound:DSOUND_PrimaryGetPosition (0x7fe03ab8,0x7fa6fa80,(nil)) > trace:wave:IDsDriverBufferImpl_GetPosition hw_ptr=0x00000000, > playpos=0, writepos=-1, mmap_buflen_bytes=15052 > trace:dsound:DSOUND_PrimaryGetPosition playpos = 0, writepos = 0 > (0x7fe03ab8, time=1913) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 0, > writepos = 0 (0x7fe03ab8, time=1913) > ds3d.c:230:buf size=22050 last_play_pos=0 play_pos=0 played=0 / > 220500, fraction_played=0 > ds3d.c:248:offset=15052 free=6998 written=15052 / 220500 > > ... > ds3d.c:230:buf size=22050 last_play_pos=10296 play_pos=11700 > played=11700 / 220500, fraction_played=1404 > ds3d.c:248:offset=10296 free=1404 written=32346 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=11700 play_pos=13104 > played=13104 / 220500, fraction_played=1404 > ds3d.c:248:offset=11700 free=1404 written=33750 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=13104 play_pos=14508 > played=14508 / 220500, fraction_played=1404 > ds3d.c:248:offset=13104 free=1404 written=35154 / 220500 > ds3d.c:230:buf size=22050 last_play_pos=14508 play_pos=860 > played=22910 / 220500, fraction_played=8402 > ds3d.c:248:offset=14508 free=8402 written=36558 / 220500 > > Please note that the play_pos wrapped from 14508 to 860 because it > exceeded 15052 bytes, but the test assumes it wrapped around at 22050 > bytes, so it miscalculates the fraction_played, advancing it at an > abnormally fast rate. That is how the following result ensues: > > trace:dsound:DSOUND_PrimaryGetPosition playpos = 176, writepos = 0 > (0x7fe03ab8, time=5366) > trace:dsound:PrimaryBufferImpl_GetCurrentPosition playpos = 176, > writepos = 0 (0x7fe03ab8, time=5366) > ds3d.c:230:buf size=22050 last_play_pos=13824 play_pos=176 > played=220676 / 220500, fraction_played=8402 > ds3d.c:237:all the samples have been played, stopping... > ds3d.c:279:stopping playback > trace:dsound:PrimaryBufferImpl_Stop (0x7fe143b8) > ds3d.c:628: Test failed: The sound played for 3453 ms instead of 5000 ms > > Many other tests with formats other than U8, 11025Hz fail for the same > reason. Any other DirectSound application that reuses the buffer size > as the test does will fail in the same way (music mixing up and > prematurely stopping). However, I am to understand that this test > passes on Windows, in all versions. > > Now that I have found the issue, I ask for help in suggesting a proper > fix. I think that the ALSA implementation used to have a separate > buffer from which samples were copied into the hardware buffer, but > this implementation was scrapped for some reason (and I think, without > re-running the ALSA tests). So I tried using > snd_hw_params_set_buffer_size() - it fails to set the buffer size to > the previously reported size. So I am still thinking about this. Any > comments or suggestions for fixing this will be greatly appreciated. > > BTW, does the DirectSound API allow the application to access the > hardware mmap directly (that is, not just by specifying the buffer to > be played)? If not, one possible solution would be to remember the > first reported buffer size, and wrap the *reported* position around at > that buffer size, even when the ALSA playback uses the real buffer > size. However, when I tried to do this (by hardcoding 22050 as a > wraparound value, just as a test), Wine promptly crashed, so I need > more insight into this. > > Alex Villacís Lasso > Resending because previous attempt probably was rejected due to gigantic attachment (my bad).

Aug. 11, 2005

Re:As to change $HOME/.wine for $HOME/.my-configuration ?

by Fabio Duarte Vilas Boas

As to change $HOME/.wine for $HOME/.my-configuration ? My english is BAD, very BAD Talking from Brazil :( --- Dustin Navea <speeddymon(a)gmail.com> escreveu: > Yet another example of babelfish mangling... lol > > Dustin > > Fabio Duarte Vilas Boas wrote: > > How dumb the directory of configuration of wine of > > $HOME/.wine for $HOME/.my-config? > > > > > > > > > > > > > _______________________________________________________ > > > Yahoo! Acesso Grátis - Internet rápida e grátis. > > Instale o discador agora! > http://br.acesso.yahoo.com/ > > > > > > > __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/

Aug. 11, 2005

Nifty FIXME hack

by Tim Schmidt

I was looking at a new (to me) video editor for Linux and noticed the author had put together a rather nice system for tracking (and presumably obliterating) his FIXME's. Here's the link: http://diva.mdk.org.pl/2005/08/03/fix-the-fixme Or, if you want to skip straight to the result, here's what it produces (try clicking on the FIXME's): http://diva.mdk.org.pl/wp-content/fixmes.html Just thought you guys may find something like this marginally useful. Hope I helped ;)

Aug. 11, 2005

Re: How dumb the directory of configuration of wine of $HOME/.wine for $HOME/.my-config?

by Dustin Navea

Yet another example of babelfish mangling... lol Dustin Fabio Duarte Vilas Boas wrote: > How dumb the directory of configuration of wine of > $HOME/.wine for $HOME/.my-config? > > > > > > _______________________________________________________ > Yahoo! Acesso Grátis - Internet rápida e grátis. > Instale o discador agora! http://br.acesso.yahoo.com/ > >

Aug. 11, 2005

How dumb the directory of configuration of wine of $HOME/.wine for $HOME/.my-config?

by Fabio Duarte Vilas Boas

How dumb the directory of configuration of wine of $HOME/.wine for $HOME/.my-config? _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

Aug. 11, 2005

Re: theming: combobox

by Frank Richter

On 11.08.2005 18:03, Dimi Paun wrote: > Wrong patch. Whoops, thanks. -f.r.

Aug. 11, 2005

Re: compile error in current cvs

by Stefan Leichter

Am Donnerstag, 11. August 2005 10:30 schrieb Mike McCormack: > Stefan Leichter wrote: > > current cvs does not compile for me. Im on SuSE 9.0. > > Hi Stefan, > > Could you please try running "./configure && make depend && make" again, > and if that doesn't work, let me know what the output of the following > command is: > > grep XML2 config.status > > For me it looks like this: > > s,@XML2LIBS@,-lxml2 -lpthread -lz -lm ,;t t > s,@XML2INCL@,-I/usr/include/libxml2 ,;t t > ${ac_dA}HAVE_LIBXML2${ac_dB}HAVE_LIBXML2${ac_dC}1${ac_dD} > ${ac_uA}HAVE_LIBXML2${ac_uB}HAVE_LIBXML2${ac_uC}1${ac_uD} > Hi Mike, nothing changed. Here is the output of the grep on my config.status after doing "../wine/configure && make depend && make" (i am doing "out of tree" builds) s,@XML2LIBS@,,;t t s,@XML2INCL@,,;t t ${ac_dA}HAVE_LIBXML2${ac_dB}HAVE_LIBXML2${ac_dC}1${ac_dD} ${ac_uA}HAVE_LIBXML2${ac_uB}HAVE_LIBXML2${ac_uC}1${ac_uD} Thanks Stefan

Aug. 11, 2005

Re: theming: combobox

by Dimi Paun

From: "Frank Richter" <frank.richter(a)gmail.com> > Frank Richter <frank.richter(a)gmail.com> > Add initial combo box theming. Wrong patch. -- Dimi Paun <dimi(a)lattica.com> Lattica, Inc.

Aug. 11, 2005

Re: x11drv: proper visible region handling for cached dces

by Alexandre Julliard

Frank Richter <frank.richter(a)gmail.com> writes: > Frank Richter <frank.richter(a)gmail.com> > Fix issue where it could happen that, when a cached dce was reused, the > visible region was not updated although the window region had changed > since the last dce use. Now, track is kept of window region changes and > the visible region for a cached dce is updated if the window region > changed in the mean time. You should use invalidate_dce() instead. -- Alexandre Julliard julliard(a)winehq.org

Aug. 11, 2005