July 2006 - Wine-Devel - list.winehq.org

Re: Slow EULA display patch

by Troy Rollo

On Saturday 01 July 2006 15:59, Krzysztof Foltman wrote: > Well, *great* to see that solved in the Wine core, but I still think I > have a bug in RichEdit, because the original (native) riched20 works > fast, despite the bug you just fixed. All that means is that the native rich edit control doesn't make the same calls you do, which is to be expected since you didn't write the native rich edit control. -- troy(a)troy.rollo.name - Sydney, Australia

July 1, 2006

Re: Call for volunteer: dwarf2 testing

by Eric Pouech

Paul Romanyszyn wrote: > This app is downloadable and takes only a few steps to reproduce. Thanks for testing Paul... the app is not the culprit as the fault occurs while loading kernel32 debug information... you should get the same error for any app you load under winedbg (if you load kernel32 symbols) that's why you get endless errors: crash in winedbg, which (as any app) relaunches winedbg for a debugging... (and moreover, it seems there are 16bit related issues in winedbg, but that's a different story) > > fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 ok, the first patch did fix the error, but now we run into another one I'll fix it later > wine: Unhandled page fault on read access to 0x55ac7760 at address > 0x7faba0f8 (thread 0012), starting debugger... > WineDbg starting on pid 0x11 > Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit > code (0x7faba0f8). > fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 > information for dbghelp<elf> > fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 > wine: Unhandled page fault on read access to 0x55ac7760 at address > 0x7faba0f8 (thread 0014), starting debugger... > WineDbg starting on pid 0x13 > Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit > code (0x7faba0f8). > fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 > information for dbghelp<elf> > fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 > wine: Unhandled page fault on read access to 0x55ac7760 at address > 0x7faba0f8 (thread 0016), starting debugger... > WineDbg starting on pid 0x15 > Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit > code (0x7faba0f8). > fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 > information for dbghelp<elf> > fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 > wine: Unhandled page fault on read access to 0x55ac7760 at address > 0x7faba0f8 (thread 0018), starting debugger... > WineDbg starting on pid 0x17 > Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit > code (0x7faba0f8). > .... > continues until ctrl C > >

July 1, 2006

Re: Call for volunteer: dwarf2 testing

by Paul Romanyszyn

Eric Pouech wrote: > running a 16 bit application from bug Bug 5493 > >> now gives an a continuous list of >> fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 >> instead of continuous page faulting between on the lookup. >> What traces do you need and I will add them to that bug. >> > does the attached patch help ? > A+ > >------------------------------------------------------------------------ > >>From nobody Mon Sep 17 00:00:00 2001 >From: Eric Pouech <eric.pouech(a)wanadoo.fr> >Date: Sat, 1 Jul 2006 11:38:10 +0200 >Subject: [PATCH] [DbgHelp]: dwarf & variable with const values > >- properly handle variable with const value (ie without > location) in dwarf code > >--- > > dlls/dbghelp/dwarf.c | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) > >5d683a5bfdb679fe617ced7b9070756c29d45a85 >diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c >index 01250a5..a618986 100644 >--- a/dlls/dbghelp/dwarf.c >+++ b/dlls/dbghelp/dwarf.c >@@ -1050,20 +1050,20 @@ static void dwarf2_parse_variable(dwarf2 > dwarf2_debug_info_t* di) > { > struct symt* param_type; >- union attribute loc; >+ union attribute name, loc, value; > BOOL is_pmt = di->abbrev->tag == DW_TAG_formal_parameter; > > TRACE("%s, for %s\n", dwarf2_debug_ctx(subpgm->ctx), dwarf2_debug_di(di)); > > param_type = dwarf2_lookup_type(subpgm->ctx, di); >- if (dwarf2_find_attribute(di, DW_AT_location, &loc)) >+ dwarf2_find_name(subpgm->ctx, di, &name, "parameter"); >+ if (dwarf2_find_attribute(di, DW_AT_location, &loc) && loc.block) > { > union attribute name; > union attribute ext; > long offset; > int in_reg; > >- dwarf2_find_name(subpgm->ctx, di, &name, "parameter"); > offset = dwarf2_compute_location(subpgm->ctx, loc.block, &in_reg); > TRACE("found parameter %s/%ld (reg=%d) at %s\n", > name.string, offset, in_reg, dwarf2_debug_ctx(subpgm->ctx)); >@@ -1094,6 +1094,10 @@ static void dwarf2_parse_variable(dwarf2 > break; > } > } >+ if (dwarf2_find_attribute(di, DW_AT_const_value, &value)) >+ { >+ FIXME("NIY (const value %08lx for %s\n", value.uvalue, name.string); >+ } > if (is_pmt && subpgm->func && subpgm->func->type) > symt_add_function_signature_parameter(subpgm->ctx->module, > (struct symt_function_signature*)subpgm->func->type, > > This app is downloadable and takes only a few steps to reproduce. Recompiled with that patch using the CFLAGS="$CFLAGS -gdwarf-2" ./configure and this it the console output wine: Unhandled page fault on read access to 0x00001d88 at address 0x18e7:0x000018d2 (thread 0010), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x00001d88 in 16-bit code (18e7:18d2). fixme:dbghelp:addr_to_linear Failed to linearize address 101a:00009f0d (mode 0) In 16 bit mode. Register dump: CS:18e7 SS:1b37 DS:191f ES:1a6f FS:003b GS:0033 IP:18d2 SP:540e BP:5416 FLAGS:0206( - 00 - RIP1) AX:500e BX:5422 CX:0000 DX:0000 SI:0000 DI:1c10 Stack dump: 0x1b37:0x540e: 1c10 0000 18e7 1b37 5485 153b 1a9f 0000 0x1b37:0x541e: 0032 0000 5436 0944 18e7 1270 1ba7 0008 0x1b37:0x542e: 1d5c 0000 0032 1b37 5441 1481 1ab7 0008 0323: sel=191f base=7fe30818 limit=00002d9f 16-bit rw- 034d: sel=1a6f base=7deac750 limit=00001fff 16-bit rw- fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000119 Backtrace: =>1 0x18e7:0x18d2 (0x18e7:0x18d2) 2 0x1a9f:0x153b (0x1a9f:0x153b) 3 0x101a:0x9f0d (0x101a:0x9f0d) 4 0x1aef:0x1cdf (0x1aef:0x1cdf) 5 0x1aef:0x1b9e (0x1aef:0x1b9e) 6 0x1b17:0x1447 (0x1b17:0x1447) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 wine: Unhandled page fault on read access to 0x55ac7760 at address 0x7faba0f8 (thread 0012), starting debugger... WineDbg starting on pid 0x11 Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit code (0x7faba0f8). fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for dbghelp<elf> fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 wine: Unhandled page fault on read access to 0x55ac7760 at address 0x7faba0f8 (thread 0014), starting debugger... WineDbg starting on pid 0x13 Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit code (0x7faba0f8). fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for dbghelp<elf> fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 wine: Unhandled page fault on read access to 0x55ac7760 at address 0x7faba0f8 (thread 0016), starting debugger... WineDbg starting on pid 0x15 Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit code (0x7faba0f8). fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for dbghelp<elf> fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 wine: Unhandled page fault on read access to 0x55ac7760 at address 0x7faba0f8 (thread 0018), starting debugger... WineDbg starting on pid 0x17 Unhandled exception: page fault on read access to 0x55ac7760 in 32-bit code (0x7faba0f8). .... continues until ctrl C

July 1, 2006

Re: Any chances to get some feedback on latests mswsock patch?

by Juan Lang

Hi Lukasz, you probably didn't notice that most patches didn't get through this week. There were several other rather large series sent, in addition to the usual traffic. My guess is Alexandre only had time for the easy ones this week. Your patches looked pretty good. The only suggestion I'd make with the documentation patch is not to say things that aren't true yet. The notes about the implementation won't be correct until the implementation patch is applied, and you shouldn't count on that. In particular, - * TODO - * This function is currently implemented as a stub.perhaps leave this as-is.. + * BUGS + * lpOverlapped->OffsetHigh is not supported. + * limited to ULONG files size (see above) + * doesn't support TF_REUSE_SOCKET + * doesn't support async IO. Note: some of it is simulated via lpOverlapped. and omit this until the implemenation patch. Cheers, --Juan

July 1, 2006

Re: WRT failed to Build

by Detlef Riekenberg

On Friday, 26. Mai 2006 Detlef Riekenberg wrote: > Am Mittwoch, den 24.05.2006, 20:24 +0200 schrieb Stefan Leichter: > > > > The cross-compiled WRT failed since 17. May. > > > I have already send a patch to Paul, to fix the cross compiling, > > Many Thanks. > > > > but it looks like Paul is not "at home". > > Let's wait for him together. Any recent Info's about WRT / Paul Millar? -- By By ... ... Detlef

July 1, 2006

Re: Wine 0.9.16 and ddraw issues

by Stefan Dösinger

Hi, > I looked at that, and it is a reference counting issue. Red alert deals > nicely with its surfaces and the ddraw object itself, but it creates a > palette and doesn't release it. A palette holds a reference to the > DirectDraw interface it was created from, this is shown by a test case I > sent some days ago. Because the palette isn't released, the final release > call of the DirectDraw interface returns 1 instead of the apparently > expected 0. On windows 95 it apparently gets a final refcount of 0, I could > imaging that reference counting is different in older ddraw interfaces, or > that there is some call which implicitly releases all palettes(I can only > imaging > IDirectDraw::RestoreDisplayMode) > > This worked in the old directdraw version because it (incorrectly) didn't > AddRef the device when a Palette was created. I have an update on that: A quick test showed that while IDirectDraw7::CreatePalette addrefs the interface as shown in my refcount test, IDirectDraw::CreatePalette doesn't do so. So the 2 DirectDraw interface versions behave differently here. This is related to the refcounting issue Star wars racer is having: http://bugs.winehq.com/show_bug.cgi?id=5007

July 1, 2006

Re: Wine 0.9.16 and ddraw issues

by Stefan Dösinger

Hi, > Command & Conquer and C&C: Red Alert > When exiting the game, a messagebox displays: 'Unregonized Direct Draw > result code: 1' > A demo of Red Alert is available here: > http://appdb.winehq.org/appview.php?versionId=4026 > These two games, along with 'Warlords IIII: Darklords Rising' also have a > strange SMP problem. In earlier Wine versions, these games would stop > redrawing at some point. This also happens in Wine 0.9.16, but sometimes > an error message is displayed instead, and then Wine receives a page fault. I looked at that, and it is a reference counting issue. Red alert deals nicely with its surfaces and the ddraw object itself, but it creates a palette and doesn't release it. A palette holds a reference to the DirectDraw interface it was created from, this is shown by a test case I sent some days ago. Because the palette isn't released, the final release call of the DirectDraw interface returns 1 instead of the apparently expected 0. On windows 95 it apparently gets a final refcount of 0, I could imaging that reference counting is different in older ddraw interfaces, or that there is some call which implicitly releases all palettes(I can only imaging IDirectDraw::RestoreDisplayMode) This worked in the old directdraw version because it (incorrectly) didn't AddRef the device when a Palette was created.

July 1, 2006

Any chances to get some feedback on latests mswsock patch?

by Łukasz Chróst

Especially i'd like to know why it hasn't been accepted. It would be nice to have some starting point in the tree, as i've much more done but can't send it anyway. :/ It would be a lot of work to cut the patches into smaller parts at some point. Especially with no feedback... -- thanks, Łukasz Chróst

July 1, 2006

Re: Win64 patch 3/5 (winedbg)

by Eric Pouech

Ge van Geldorp wrote: >>From: Eric Pouech [mailto:eric.pouech(a)wanadoo.fr] >> >>this one is questionnable. Now that we have stackwalk64 >>implemented (I'm not saying it works flawlessly on 64bit >>machines), it may be more interesting here to use the 64 bit >>version of the call back >> >> > >That's actually a separate issue. The problem I'm trying to solve here is >that the last parameter of ReadProcessMemory (which is the API that is >eventually called by pcs->process_io->read()) is defined as SIZE_T *, which >expands to a pointer to 8 bytes on Win64. The last parameter of the >ReadMemoryRoutine callback of StackWalk is PDWORD, pointer to 4 bytes. So >you can't pass the last parameter of the ReadMemoryRoutine callback on to >pcs->process_io->read(), you'd write 8 bytes to a 4 byte variable. > > I read it too quickly, you're right.

July 1, 2006

Re: Call for volunteer: dwarf2 testing

by Eric Pouech

running a 16 bit application from bug Bug 5493 > now gives an a continuous list of > fixme:dbghelp_dwarf:dwarf2_compute_location Unhandled attr op: 75 > instead of continuous page faulting between on the lookup. > What traces do you need and I will add them to that bug. > does the attached patch help ? A+ >From nobody Mon Sep 17 00:00:00 2001 From: Eric Pouech <eric.pouech(a)wanadoo.fr> Date: Sat, 1 Jul 2006 11:38:10 +0200 Subject: [PATCH] [DbgHelp]: dwarf & variable with const values - properly handle variable with const value (ie without location) in dwarf code --- dlls/dbghelp/dwarf.c | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) 5d683a5bfdb679fe617ced7b9070756c29d45a85 diff --git a/dlls/dbghelp/dwarf.c b/dlls/dbghelp/dwarf.c index 01250a5..a618986 100644 --- a/dlls/dbghelp/dwarf.c +++ b/dlls/dbghelp/dwarf.c @@ -1050,20 +1050,20 @@ static void dwarf2_parse_variable(dwarf2 dwarf2_debug_info_t* di) { struct symt* param_type; - union attribute loc; + union attribute name, loc, value; BOOL is_pmt = di->abbrev->tag == DW_TAG_formal_parameter; TRACE("%s, for %s\n", dwarf2_debug_ctx(subpgm->ctx), dwarf2_debug_di(di)); param_type = dwarf2_lookup_type(subpgm->ctx, di); - if (dwarf2_find_attribute(di, DW_AT_location, &loc)) + dwarf2_find_name(subpgm->ctx, di, &name, "parameter"); + if (dwarf2_find_attribute(di, DW_AT_location, &loc) && loc.block) { union attribute name; union attribute ext; long offset; int in_reg; - dwarf2_find_name(subpgm->ctx, di, &name, "parameter"); offset = dwarf2_compute_location(subpgm->ctx, loc.block, &in_reg); TRACE("found parameter %s/%ld (reg=%d) at %s\n", name.string, offset, in_reg, dwarf2_debug_ctx(subpgm->ctx)); @@ -1094,6 +1094,10 @@ static void dwarf2_parse_variable(dwarf2 break; } } + if (dwarf2_find_attribute(di, DW_AT_const_value, &value)) + { + FIXME("NIY (const value %08lx for %s\n", value.uvalue, name.string); + } if (is_pmt && subpgm->func && subpgm->func->type) symt_add_function_signature_parameter(subpgm->ctx->module, (struct symt_function_signature*)subpgm->func->type, -- 1.3.3

July 1, 2006