March 2007 - Wine-Devel - list.winehq.org

Anyone else want to be a SoC mentor?

by Dan Kegel

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

March 31, 2007

Re: extracting info from a minidump via winedbg

by Dennis Schridde

Am Samstag, 31. März 2007 schrieb Eric Pouech: > >> what does 'winedbg -x debug -g warzone2100.exe' give ? > > > > Usage information... > > > > winedbg has neither a -x nor a -g parameter. > > winedump has a -x parameter (which takes no option) and a -G parameter. > > It complains about not being able to treat multiple files. > > So you probably meant a completely different tool... > > I actually meant > winedump dump -x debug -G warzone2100.exe Still does not work... "Only one file can be treated at once" --Dennis

March 31, 2007

Re: extracting info from a minidump via winedbg

by Eric Pouech

Dennis Schridde a écrit : > Am Freitag, 30. März 2007 schrieb Eric Pouech: > >> 2007/3/29, Dennis Schridde <devurandom(a)gmx.net>: >> >>> Am Donnerstag, 29. März 2007 schrieb Eric Pouech: >>> >>>> Dennis Schridde a écrit : >>>> >>>>> 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: >>>>> >>>>> [...] >>>>> >>>>> 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? >>>>> >>>> because it needs the original PE files (.exe, .dll) to get to the debug >>>> information >>>> those files must be seated in directories listed in the _NT_SYMBOL_PATH >>>> environment variable >>>> >>> Maybe I am just doing it wrong, but >>> _NT_SYMBOL_PATH=. winedbg warzone2100.mdmp >>> doesn't change anything... (Even supplying the full path doesn't.) >>> The exe (not all dlls, because I don't have a copy of the user's system) >>> is of >>> course in the working directory. >>> >> But the debug info is not always in the .exe itself. the .exe can contain >> only a pointer to the debug info >> > This exe was compiled using the GCC switch "-g" and was not striped > afterwards, it is ~10MB big (the usual size of our app when compiled in debug > mode) and winedump drops a long list of I don't know what when I > run "winedump -G warzone2100.exe". > > >> what does 'winedbg -x debug -g warzone2100.exe' give ? >> > Usage information... > > winedbg has neither a -x nor a -g parameter. > winedump has a -x parameter (which takes no option) and a -G parameter. It > complains about not being able to treat multiple files. > So you probably meant a completely different tool... > I actually meant winedump dump -x debug -G warzone2100.exe > >>>> - Why doesn't winedbg show me the other information included in the >>>> >>>> >>>>> minidump, like the loaded modules, commandline options or version >>>>> information? >>>>> >>>> 'info share' should do part of it... winedbg doesn't show the command >>>> line info nor options >>>> >>> That only shows me the memory ranges of some modules. The minidump >>> includes >>> more info, like the paths to dlls and similar. I am not sure whether it >>> includes version information, but it certainly contains the commandline >>> used >>> to start the app. >>> >>> >>>> other thing you can do is to use winedump (man winedump) >>>> >>> How do I do this? And what will it provide? I tried >>> winedump -G warzone2100.exe >>> but I have no idea what I shall do with that tremedously long and cryptic >>> list. >>> >> winedump warzone2100.mdmp >> > This is actually useful. Things like file versions, modules and so on are > printed. What's still missing (and only visible in the binary listing > of "Memory ranges" is the commandline. > Are there plans to make this info accessible from winedbg? > Or to include things like backtrace information into winedump? > the backtrace will be visibel in winedbg the command line will not be available, as it's not store (as a command line) in the minidump it's present because the minidump contains stack fragments, and the command occurs to be on the stack, but there's no easy way to link the two can you directly send me your .mdmp and .exe file so I can have a look at the details > --Dennis > > ------------------------------------------------------------------------ > > > -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

March 31, 2007

Re: Submitting AppDB test results broken?

by Alexander Nicolaysen Sørnes

Lørdag 31 mars 2007 14:42, skrev Markus: > 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, The no id defined error is just temporarily, because the testData should be handled by something called the objectManager; you are forwarded to the wrong page afterwards, that's all. They are indeed added to the database, but they won't appear until an admin or maintainer checks them. This change is quite new. The missing .34 release has to be added in BugZilla by someone with sufficient privileges. Regards, Alexander N. Sørnes

March 31, 2007

Submitting AppDB test results broken?

by Markus

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

March 31, 2007

Re: request to look into this bug

by Damjan Jovanovic

On 3/30/07, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > 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. I noticed WinMerge crashing, but I think it worked a number of wine versions back (wine-0.9.2x, with x being around 6-8). Please regression test it if you can, I don't currently have the time. May the bug hunt go well, Damjan

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Stefan Dösinger

Am Samstag 31 März 2007 13:05 schrieb Nathan Williams: > Hmm, ok it seems I'm going to have to put some more time and thought > into this patch before I try again! > > Thanks for all your help, I'll see what I can work out. > Do you know of any games that create power of 2 surfaces, so any > changes I make, I can test them against? Swat3 was the game I wrote the glrect oversize code for. > Or should I just fire up windows, and brush up on my direct draw code > to make a test app? =D That is always a good idea, especially if you add the test app to dlls/ddraw/tests/

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Nathan Williams

Hmm, ok it seems I'm going to have to put some more time and thought into this patch before I try again! Thanks for all your help, I'll see what I can work out. Do you know of any games that create power of 2 surfaces, so any changes I make, I can test them against? Or should I just fire up windows, and brush up on my direct draw code to make a test app? =D On 3/31/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Samstag 31 März 2007 11:56 schrieb Nathan Williams: > > > This->Flags |= SFLAG_NONPOW2 > This also isn't correct in that case :-) > > This will set the NONPOW2 flag unconditionally, even for surfaces which have > power of 2 sizes. If there is a surface which has non power of 2 sizes, and > the non power of 2 extension is not supported, then the bug is in > CreateSurface itself. > > If gl native np2 surfaces are supported, then NONPOW2 is never set. The name > of this flag is maybe a bit misleading. Essentially it means that the opengl > texture is bigger than the surface in memory. > > -- Nathan

March 31, 2007

Re: DirectDrawRenderer - opengl non power of 2 windows

by Stefan Dösinger

Am Samstag 31 März 2007 11:56 schrieb Nathan Williams: > > This->Flags |= SFLAG_NONPOW2 This also isn't correct in that case :-) This will set the NONPOW2 flag unconditionally, even for surfaces which have power of 2 sizes. If there is a surface which has non power of 2 sizes, and the non power of 2 extension is not supported, then the bug is in CreateSurface itself. If gl native np2 surfaces are supported, then NONPOW2 is never set. The name of this flag is maybe a bit misleading. Essentially it means that the opengl texture is bigger than the surface in memory.

March 31, 2007

DirectDrawRenderer - opengl non power of 2 windows

by Nathan Williams

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

March 31, 2007