wine-devel March 2007

wine-devel@winehq.org

162 participants
368 discussions

extracting info from a minidump via winedbg
by Dennis Schridde 01 Apr '07

01 Apr '07

Hello Wine users! I've got a minidump from a ("real") Windows user of our game and would like to extract information from it using winedbg. The information winedbg gives me by default, is this: WineDbg starting on minidump on pid 068c warzone2100.exe was running on #1 Intel ???-0.521 CPU on Windows XP (2600) Register dump: CS:001b SS:0023 DS:0023 ES:0023 FS:003b GS:0000 EIP:0051008b ESP:0022f844 EBP:0022f858 EFLAGS:00010a87( - 00 ROISP1C) EAX:c7b054d8 EBX:19ff502e ECX:00000040 EDX:0000000f ESI:02010101 EDI:00000000 Stack dump: 0x0022f844: 00000000 00000000 00000000 3f800000 0x0022f854: 00000000 0022f8c8 0050e796 19ff502e 0x0022f864: 3f800000 00000000 00000000 00000000 0x0022f874: 00000000 00000000 00000000 ff4a4a4a 0x0022f884: 00000005 02010101 00000000 00000000 0x0022f894: 00000000 0022f8c8 00000000 00000000 Backtrace: =>1 0x0051008b (0x0022f858) 2 0x0050e796 (0x0022f8c8) 3 0x00410c3b (0x0022f948) 4 0x0041172d (0x0022f9c8) 5 0x004b2272 (0x0022f9d8) 6 0x004aa97b (0x0022f9f8) 7 0x004b615a (0x0022fab8) 8 0x004b663f (0x0022fad8) 9 0x004b67e1 (0x0022faf8) 10 0x0041e39e (0x0022fb28) 11 0x00459d3e (0x0022fb58) 12 0x0045b2ee (0x0022fca8) 13 0x0055e77b (0x0022fcf8) 14 0x0055e932 (0x0022fef8) 15 0x0055e483 (0x0022fff0) 16 0x00000000 (0x00000000) WineDbg starting on pid 068c Which is pretty rare. Via addr2line I can translate the backtrace to possibly valid locations in our sourcefiles. My questions are: - Why doesn't winedbg extract the sourcecode locations itself? - Why doesn't winedbg show me the other information included in the minidump, like the loaded modules, commandline options or version information? - How can I get the parameters to the last called function(s)? If winedbg is missing the commands/functions to achive the above, I may be able to provide it. The minidump functions seem to be documented rather good on msdn and it would just require printing it to the console. Thanks in advance, Dennis

4 7

Anyone else want to be a SoC mentor?
by Dan Kegel 31 Mar '07

31 Mar '07

Hey folks, it looks like we might need a few more mentors; anyone else interested? - Dan

1 0

Submitting AppDB test results broken?
by Markus 31 Mar '07

31 Mar '07

Hi, I just noticed that submitting test data to AppDB does not work. After submitting, the result page shows several e-mails sent but also an error "No test id defined!". The test data does not show up in the result list either. In addition, the .34 release is not available for selection yet. Regards, -- Markus

2 1

request to look into this bug
by Louis. Lenders 31 Mar '07

31 Mar '07

Hi, while working through the test reports in the appdb, i saw users submitting crashes with applications , all similar to bug 7380, so i decided to take it here. The applications that crash are *WinMerge (newest version) *BookWorms Adventures + several other PopCap games ( i tested them) *5 other applications listed under bug 7380. So i know of at least 10 applications that crash this way. They all start fine using the "buggy pointer" patch from Rein Klazes below. However, i think it's becoming rahter strange that all these (just released!) applications pass buggy pointers, so i'm beginning to think the problem must be somewhere else. I've sent in a patch to work around this bug by an exception handler a few weeks ago, but that's likely not the way to go either then. Anyone an idea how to tackle this problem? Thanks. diff --git a/dlls/winex11.drv/dib.c b/dlls/winex11.drv/dib.c index cec2058..4e61da4 100644 --- a/dlls/winex11.drv/dib.c +++ b/dlls/winex11.drv/dib.c @@ -3861,6 +3861,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph X11DRV_DIB_IMAGEBITS_DESCR descr; BITMAP bitmap; LONG width, height, tmpheight; + int nrsrcbytes, dibpitch; INT result; descr.physDev = physDev; @@ -3880,6 +3881,17 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph if (startscan + lines > height) lines = height - startscan; + + /* pointer check */ + dibpitch = ((width * descr.infoBpp + 23) &~23) / 8; + if( descr.compression) + nrsrcbytes = 1; + else { + nrsrcbytes = lines * dibpitch; + if( nrsrcbytes < 0) nrsrcbytes = - nrsrcbytes; + } + if( IsBadReadPtr( bits, nrsrcbytes)) return 0; + switch (descr.infoBpp) { case 1: @@ -3926,7 +3938,7 @@ INT X11DRV_SetDIBits( X11DRV_PDEVICE *ph descr.width = bitmap.bmWidth; descr.height = lines; descr.useShm = FALSE; - descr.dibpitch = ((descr.infoWidth * descr.infoBpp + 31) &~31) / 8; + descr.dibpitch = dibpitch; X11DRV_DIB_Lock( physBitmap, DIB_Status_GdiMod, FALSE ); result = X11DRV_DIB_SetImageBits( &descr ); X11DRV_DIB_Unlock( physBitmap, TRUE ); --------------------------------- New Yahoo! Mail is the ultimate force in competitive emailing. Find out more at the Yahoo! Mail Championships. Plus: play games and win prizes.

2 1

DirectDrawRenderer - opengl non power of 2 windows
by Nathan Williams 31 Mar '07

31 Mar '07

Sorry about the last patch, I slipped up on my bitwise operators. This should be correct to my intentions at least! (I forgot to hit reply all, agh, i should probably power off my computer now :P ) On 3/31/07, Chris Bandy <cbandy(a)jbandy.com> wrote: > > > Stefan Dösinger wrote: > >> @@ -3194,6 +3193,7 @@ static HRESULT WINAPI > >> > > IWineD3DSurfaceImpl_PrivateSetup(IWineD3DSurface *iface) { > > > >> } else { > >> /* No oversize, gl rect is the full texture size */ > >> This->Flags &= ~SFLAG_OVERSIZE; > >> + This->Flags &= SFLAG_NONPOW2; > >> > > > > > > This is not correct. This removes every flag except SFLAG_NONPOW2. If you want > > to remove the SFLAG_NONPOW2 flag you have to invert the flag: > > > > This->Flags &= ~SFLAG_NONPOW2 > > > If you want to set the SFLAG_NONPOW2 flag... > > This->Flags |= SFLAG_NONPOW2 > -- Nathan -- Nathan

2 3

Re: DirectDrawRenderer - opengl non power of 2 windows
by Nathan Williams 31 Mar '07

31 Mar '07

My first patch! Sorry this took so long for such a simple patch, I have just been run off my feet until now. Before I submit this to wine-patches, is anyone able to do some further testing for me, to make sure it doesn't break any currently working games? This patch fixes a bug that causes a crash for direct draw games when using opengl as the DirectDrawRenderer. I wanted to make sure this works and is safe, before I venture into making it optimized as Stefan suggested. On 3/25/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > case WINED3DFMT_P8: > { > int height = This->glRect.bottom - This->glRect.top; <--!!! > type = GL_UNSIGNED_BYTE; > fmt = GL_RGBA; > > mem = HeapAlloc(GetProcessHeap(), 0, This->resource.size * sizeof(DWORD)); > if(!mem) { > ERR("Out of memory\n"); > return; > } > memory_allocated = TRUE; > d3dfmt_convert_surface(This->resource.allocatedMemory, > ... > > > I think the int height = This->glRect.bottom - This->glRect.top is the > problem. It should use This->currentDesc.Height instead. The opengl rectangle > is a helper for surfaces which are bigger than the max size supported by > opengl If they are used for 2D blits. For example swat3 creates a 3000x32 > surface to blit text in 32x32 rectangles. In this case only the needed area > is uploaded to gl and used for blits. > > Here the gl rectangle does not apply. For the sake of optimization you may > change the code to only convert the dirty rectangle instead of the whole > surface. > > -- Nathan

3 3

Excluding a Windows version from the tests
by Paul Vriens 31 Mar '07

31 Mar '07

Hi, yesterday a patch of mine was committed to test more profile stuff from kernel32. When I have a look now at test.winehq.org I see that some test(s) crash on win98 but not on others. Although I could use a if(0) construction (as is done in several other tests), I'm wondering if we should just not run specific tests on specific Windows versions. It's a shame that one OS version blocks the running of several other tests. I have no idea yet how to achieve this without building in GetVersion style things, as logic and return values don't always make a good distinction. Any ideas, thoughts? Cheers, Paul.

5 11

Release notes
by John Voltz 30 Mar '07

30 Mar '07

I have a question about the Wine release notes. Do the Wine developers work from bugzilla or do they usually just work on a specific application feature? Would it require too much extra effort on the release notes to associate a specific change with a bugzilla bug-fix or specific application/feature fix? I believe IMHO that this would make the release notes more relevant and useful to the end user. I never can tell what was actually fixed in a particular release because of the obscure developer notes. I've been lurking on the wine-devel list watching how development progresses, because at some point I would like to attempt joining in on the development effort. -- John Voltz

2 1

RE: [PATCH 13/18] XCOPY: Add support for /EXCLUDELIST:file1+file2 etc
by Ann & Jason Edmeades 30 Mar '07

30 Mar '07

Further investigations shows the strstr bit is right, but the string I am comparing with differs from windows. I have fixed up xcopy's output display to mirror windows, and added that as a patch on the end of the resubmitted patchset, as it is not directly related to the strstr bit Regards, Jason

1 0

Jason Edmeades : xcopy: Add support for COPYCMD override and
by Ann & Jason Edmeades 30 Mar '07

30 Mar '07

>wouldn't it be nicer to use sizeof(copyCmd) here? >if (GetEnvironmentVariable(COPYCMD, copyCmd, MAXSTRING)) { >There are many spots like this in wcmdmain.c Yes... I'm blaming cut and paste as I didn't do all the wcmd ones :-) Once I get all my xcopy patches in I want to continue my rework of the cmd commands, finishing off some more inbuilt ones which I know are broken. I also want to extend your last patch to ensure all parts which process a command line are using the MAXSTRING length, and I'll do a patch for this while I am at it. Thanks, Jason

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel March 2007