wine-devel January 2008

wine-devel@winehq.org

126 participants
290 discussions

Re: [dbghelp 10/10] Clamp minidump memory blocks to 928KB
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From 1127317807ec264541e2e03e6a633cefee8f697b Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:43:41 -0500 > Subject: [PATCH] Clamp minidump memory blocks to 928KB and improve TRACEs > WinDbg can't read minidumps with memory blocks larger than this. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/minidump.c | 35 +++++++++++++++++++++++++++++++++-- > 1 files changed, 33 insertions(+), 2 deletions(-) > > diff --git a/dlls/dbghelp/minidump.c b/dlls/dbghelp/minidump.c > index 564d824..f113728 100644 > --- a/dlls/dbghelp/minidump.c > +++ b/dlls/dbghelp/minidump.c > @@ -32,6 +32,13 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(dbghelp); > > + > +/* windbg isn't able to open minidump files if they contain a single memory block larger > + than 928KB. If a larger block is found, it simply reports that all following streams > + could not be loaded. This is as of WinDbg version 6.7.0005.1. */ > +#define MINIDUMP_MEMORY_BLOCK_MAX (928 * 1024) > + > + > struct dump_memory > { > ULONG base; > @@ -640,8 +647,32 @@ static void dump_threads(struct dump_context* dc, > } > if (mdThd.Stack.Memory.DataSize && (flags_out & ThreadWriteStack)) > { > - add_memory_block(dc, mdThd.Stack.StartOfMemoryRange, > - mdThd.Stack.Memory.DataSize, > + ULONG size; > + ULONG64 base; > + > + > + /* windbg only supports memory blocks up to 928KB in size. Not sure where that > + specific amount comes from, but in testing it will completely fail to load > + all minidump streams that follow a memory block that is larger than 928KB. > + Because of this, we'll clamp all of the memory blocks that we add to the > + file. */ > + if (mdThd.Stack.Memory.DataSize > MINIDUMP_MEMORY_BLOCK_MAX){ > + size = MINIDUMP_MEMORY_BLOCK_MAX; > + > + /* since this is the thread stack we'll want to save this block top-down > + instead of just clamping the buffer size */ > + base = mdThd.Stack.StartOfMemoryRange + (mdThd.Stack.Memory.DataSize - MINIDUMP_MEMORY_BLOCK_MAX); > + > + TRACE(" clamping the stack block starting at 0x%08llx {oldSize = %u bytes, newSize = %u bytes, newBase = 0x%08llx}\n", > + mdThd.Stack.StartOfMemoryRange, mdThd.Stack.Memory.DataSize, size, base); > + } > + > + else{ > + size = mdThd.Stack.Memory.DataSize; > + base = mdThd.Stack.StartOfMemoryRange; > + } > + > + add_memory_block(dc, base, size, > rva_base + sizeof(mdThdList.NumberOfThreads) + > mdThdList.NumberOfThreads * sizeof(mdThd) + > FIELD_OFFSET(MINIDUMP_THREAD, Stack.Memory.Rva)); > > ------------------------------------------------------------------------ > > > if that's really the case (and I'm even not sure we want to support this backward compatibility), a good fix would be to add several streams each up to 928k instead of clamping A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

Re: [dbghelp 7/10] Fix file searching to search only listed directories instead of the whole HD
by Eric Pouech 18 Jan '08

18 Jan '08

Jason Green a écrit : > ------------------------------------------------------------------------ > > From ad95ee9cad0df8b4e8ca35d2d5a280d755c7bf7f Mon Sep 17 00:00:00 2001 > From: Jason Green <jason(a)jave01.(none)> > Date: Thu, 17 Jan 2008 17:21:00 -0500 > Subject: [PATCH] Fix file searching to search only listed directories instead of the whole HD. > And, wrap some TRACE parameters in debugstr. > From: Eric van Beurden (ericvb(a)transgaming.com) > --- > dlls/dbghelp/path.c | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/dlls/dbghelp/path.c b/dlls/dbghelp/path.c > index 2e191af..fac9dc0 100644 > --- a/dlls/dbghelp/path.c > +++ b/dlls/dbghelp/path.c > @@ -57,7 +57,7 @@ HANDLE WINAPI FindDebugInfoFile(PCSTR FileName, PCSTR SymbolPath, PSTR DebugFile > { > HANDLE h; > > - h = CreateFileA(DebugFilePath, GENERIC_READ, FILE_SHARE_READ, NULL, > + h = CreateFileA(FileName, GENERIC_READ, FILE_SHARE_READ, NULL, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL); > you failed to set DebugFilePath to the desired value again the rest of the patch has nothing to do with the first part of the patch A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

1 0

problem with widl.
by Ivan Sinitsin 18 Jan '08

18 Jan '08

I have a question about widl. tools\widl\header.c function "write_method_macro" fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); for (c=0; c<argc; c++) fprintf(header, ",%c", c+'a'); fprintf(header, ")\n"); This code wrong, because if my function have more then 16 parameters I receive something like this: #define Imyinterface_Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q (p)->lpVtbl->Open(p,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q) and the compiler gives out a mistake library.h:1296:63: duplicate macro parameter "p" I think that this code should be like this: Variant 1. int p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header, "(p"); p=0; for (c=0; c<argc; c++) { if (p==15) p++; fprintf(header, ",%c", p+'a'); p++; } fprintf(header, ")\n"); or Variant 2. (Without cycles) char str[] = {'p',',','a',',','b',',','c',',','d',',','e',',','f',',','g',',','h',',','i',',','j',',','k',',','l',',','m',',','o',',','q',',','r',',','s',',','t',',','u',',','v',',','w',',','x',',','y',',','z',',',0}; str[2*argc+1] = 0; fprintf(header, "#define %s_", name); write_name(header,def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ") "); fprintf(header, "(p)->lpVtbl->"); write_name(header, def); fprintf(header,"("); fprintf(header,"%s",str); fprintf(header, ")\n"); What do you think about that? ---------------- Sinitsin Ivan

2 1

Debugger unhappiness blocking valgrind runs
by Dan Kegel 18 Jan '08

18 Jan '08

I just tried to do another daily valgrind run, but it got blocked because it started up an infinite number of copies of winedbg. It seems that a crash in the imagelist test in GetDibBits triggered winedbg, and winedbg crashed trying to generate a backtrace, which of course fired up winedbg, which... was bad. Some of the logs are at http://bugs.winehq.org/show_bug.cgi?id=11211 This seems to be very recent breakage, either today or yesterday. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

3 3

Re: [dbghelp 4/10] Rewrite much of the symbol lookup method to work with Optimized PDB files as well
by Alexandre Julliard 18 Jan '08

18 Jan '08

"Jason Green" <jave27(a)gmail.com> writes: > + > +#ifdef TRACE_SYMBOL_LIST > + TRACE("\n\n***** sorting the table {count = %d}\n\n", module->num_sorttab); > +#endif > + > + qsort(module->addr_sorttab, module->num_sorttab, sizeof(struct symbol_entry), symt_cmp_addr_and_size); > + > + generateSymbolChains(module); > + > + > +#ifdef TRACE_SYMBOL_LIST > + if (0){ > + ULONG64 prevAddr = 0; Please don't add ifdef'ed out code, it should either be compiled always, or removed completely. > + sizeof(SYMBOL_INFO), Symbol->SizeOfStruct, > + (intptr_t)&Symbol->SizeOfStruct - (intptr_t)Symbol, > + (intptr_t)&Symbol->TypeIndex - (intptr_t)Symbol, > + (intptr_t)&Symbol->Reserved[0] - (intptr_t)Symbol, Don't use stdint.h types, there are Win32 types for that. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: qmgr [1/3]: Implement IClassFactory methods.
by Alexandre Julliard 18 Jan '08

18 Jan '08

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > I split the last patch into three. This is essentially the same as the last > one Roy sent, but cleaned up a bit. This adds the IClassFactory methods for > BITS. When sending a patch written by someone else, please include a From: line with the proper attribution in your message. -- Alexandre Julliard julliard(a)winehq.org

1 0

appdb hosed
by Dan Kegel 18 Jan '08

18 Jan '08

The left nav bars are broken, can't approve any new test data.

2 3

re: add HKLM/System/MountedDevices to be added by default
by Dan Kegel 18 Jan '08

18 Jan '08

c.f. wrote: > this is suggested on quite some places in appdb to make seucrom based games come a litle further Discussed at http://bugs.winehq.org/show_bug.cgi?id=7065#c58 Looks like something of this sort is already in, you must have blinked :-)

1 0

add HKLM/System/MountedDevices to be added by default
by Christoph Frick 17 Jan '08

17 Jan '08

this is suggested on quite some places in appdb to make seucrom based games come a litle further --- tools/wine.inf | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/tools/wine.inf b/tools/wine.inf index c3cb89c..f63fb23 100644 --- a/tools/wine.inf +++ b/tools/wine.inf @@ -362,6 +362,8 @@ HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-99 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"IsInstalled",2,1 HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Locale",2,"*" HKLM,SOFTWARE\Microsoft\Active Setup\Installed Components\{de5aed00-a4bf-11d1-9948-00c04f98bbc9},"Version",2,"4,74,9273,0" +; SecuROM needs this key +HKLM,System\MountedDevices,,,"" [Nls] HKLM,System\CurrentControlSet\Control\Nls\Codepage,"37",,"" -- 1.5.3.7

2 2

Re: [PATCH] support for synchronous and non-buffered I/O
by Dave Hansen 17 Jan '08

17 Jan '08

On Tue, 2008-01-15 at 23:10 -0800, Dave Hansen wrote: > I have a little Eye-Fi card (http://www.eye.fi). The software to > control it is a windows application that writes to control files which > appear in a DOS filesystem on the SD card. (you can read more > information here: http://dave-hansen.blogspot.com/) > > However, the application does not quite work under wine. The > application writes to the card, but doesn't get the results it expects. > It loops doing read()s of the files looking for results until it times > out. Do me a favor and don't apply this quite yet. I'll repost when it's ready. -- Dave

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
29
Older →

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 January 2008