wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: RegSetValueEx problem?
by gerard patel 08 Apr '01

08 Apr '01

At 10:54 AM 08/04/2001 +0100, you wrote: > >I've found time to do some more digging, but I'm still stumped. <snip> I have browsed server/registry.c and it seems that the registry stores a terminating null for strings; so if you have in the registry file a string like "0123456789", it get in memory a length of 11. So I guess that the fix would be to fix the length by -1 somewhere in the path server->ntdll->advapi I have tried this but I am not sure at all this is correct : --- registry.c.orig Mon Mar 5 20:34:21 2001 +++ registry.c Sun Apr 8 18:11:39 2001 @@ -799,14 +799,17 @@ struct key_value *value; int index; size_t ret = 0; + size_t l; if ((value = find_value( key, name, &index ))) { *type = value->type; - *len = value->len; - if (value->data && offset < value->len) + l = value->len; + if ((value->type == REG_SZ) && l) l--; + *len = l; + if (value->data && offset < l) { - if (maxlen > value->len - offset) maxlen = value->len - offset; + if (maxlen > l - offset) maxlen = l - offset; memcpy( data, (char *)value->data + offset, maxlen ); ret = maxlen; } Gerard

2 1

Wrc question
by gerard patel 08 Apr '01

08 Apr '01

I have looked at wrc code and there is a strange 100K limit on the size of mem allocation : assert(size > 0); assert(size < 102400); res = malloc(size); if(res == NULL) { Baffling code - hardcoded limit hidden in a C file :-/ I removed the assert and wrc was able to handle a 1 megabyte bitmap. Anyone has an idea about the meaning of this limit ? Gerard

2 1

Re: debugger startup
by gerard patel 08 Apr '01

08 Apr '01

At 06:32 PM 07/04/2001 +0200, you wrote: <snip> >the setup was that the AeDebug registry key pointed to a shell script, >which in turn, >launched the real debugger (used to set up different context options, >and such) ah that was the problem ? from the bug reports on the news group I had the idea that the key was just not initialized. <snip> >either we decide that shell scripts shouldn't be used (easy solution) The script has an utility, no ? I don't know what it's doing, is the goal to configure the debugger options ? (if yes, maybe using an environment variable could give the same result ??) Gerard

1 0

Re: RegSetValueEx problem?
by davep 08 Apr '01

08 Apr '01

On Sun, 01 Apr 2001, you wrote: > At 01:59 PM 31/03/2001 +0100, you wrote: > > <snip> > >Compiling and running Winemine under Windows 95 this problem doesn't occur. > >Win95 truncates the value at the first null. > > Under NT4 SP6, if I write (for example) '47' + 0 + 13 bytes of garbage, I get > exactly that when querying with the same buffer length (16). > If I use a longer buffer, one binary 0 is appended. > If I use a shorter buffer, nothing is copied and the function does not succeed > (ERROR_MORE_DATA). > > Of course under Regedit the garbage is not displayed; regedit displays only '47' > in this case. I've found time to do some more digging, but I'm still stumped. This is the trace from WineMine saving one parameter in the registry (-debugmsg +relay,+reg): Call advapi32.248: RegSetValueExA(00000038,4038cae0 "Xpos",00000000,00000001,405e66a0,00000010) ret=40388dc8 fs=008f Call kernel32.643: MultiByteToWideChar(00000000,00000000,405e66a0 "3",00000010,00000000,00000000) ret=407c4fe9 fs=008f Ret kernel32.643: MultiByteToWideChar() retval=00000010 ret=407c4fe9 fs=008f Call kernel32.553: HeapAlloc(40390000,00000000,00000020) ret=407c4fff fs=008f Ret kernel32.553: HeapAlloc() retval=403d62fc ret=407c4fff fs=008f Call kernel32.643: MultiByteToWideChar(00000000,00000000,405e66a0 "3",00000010,403d62fc,00000010) ret=407c5023 fs=008f Ret kernel32.643: MultiByteToWideChar() retval=00000010 ret=407c5023 fs=008f Call ntdll.419: RtlInitAnsiString(405e658c,4038cae0 "Xpos") ret=407c5038 fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000000 ret=407c5038 fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(40113578,405e658c,00000000) ret=407c504d fs=008f Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c504d fs=008f Call ntdll.230: NtSetValueKey(00000038,40113578,00000000,00000001,403d62fc,00000020) ret=407c5067 fs=008f trace:reg:NtSetValueKey (0x38,L"Xpos",1,0x403d62fc,32) Ret ntdll.230: NtSetValueKey() retval=00000000 ret=407c5067 fs=008f Call kernel32.559: HeapFree(40390000,00000000,403d62fc) ret=407c5083 fs=008f Ret kernel32.559: HeapFree() retval=00000001 ret=407c5083 fs=008f Call ntdll.466: RtlNtStatusToDosError(00000000) ret=407c5089 fs=008f Ret ntdll.466: RtlNtStatusToDosError() retval=00000000 ret=407c5089 fs=008f Ret advapi32.248: RegSetValueExA() retval=00000000 ret=40388dc8 fs=008f So the 16-byte buffer (containing the character "3", a null, and 14 bytes of garbage) has been converted into a 32-byte unicode string and saved. Good. Inside the registry this looks like: "Xpos"="3\0\0\0`\x00ca7@\0\0\0\0\0\0\0@" Now if we read that value back in this is what happens: Call advapi32.236: RegQueryValueExA(00000034,4038cae0 "Xpos",00000000,405e6970,405e697c,405e6974) ret=40388a38 fs=008f trace:reg:RegQueryValueExA (0x34,"Xpos",(nil),0x405e6970,0x405e697c,0x405e6974=16) Call ntdll.419: RtlInitAnsiString(405e6764,4038cae0 "Xpos") ret=407c5565 fs=008f Ret ntdll.419: RtlInitAnsiString() retval=00000000 ret=407c5565 fs=008f Call ntdll.281: RtlAnsiStringToUnicodeString(40113578,405e6764,00000000) ret=407c557a fs=008f Ret ntdll.281: RtlAnsiStringToUnicodeString() retval=00000000 ret=407c557a fs=008f Call ntdll.177: NtQueryValueKey(00000034,40113578,00000002,405e676c,00000100,405e6760) ret=407c55b0 fs=008f trace:reg:NtQueryValueKey (0x34,L"Xpos",2,0x405e676c,256) Ret ntdll.177: NtQueryValueKey() retval=00000000 ret=407c55b0 fs=008f Call kernel32.889: WideCharToMultiByte(00000000,00000000,405e6778 L"3",00000011,00000000,00000000,00000000,00000000) ret=407c56c9 fs=008f Ret kernel32.889: WideCharToMultiByte() retval=00000011 ret=407c56c9 fs=008f Call ntdll.466: RtlNtStatusToDosError(80000005) ret=407c57be fs=008f Ret ntdll.466: RtlNtStatusToDosError() retval=000000ea ret=407c57be fs=008f Ret advapi32.236: RegQueryValueExA() retval=000000ea ret=40388a38 fs=008f RegQueryValueEx maintains that there are 17 characters and since they won't fit in the buffer the function aborts. Incidentally, the "null-terminate if the user forgot" trick is carried out both in RegSetValueEx *and* RegQueryValueEx. Would not once be enough? -- Dave Pickles

1 0

debugger startup
by eric pouech 07 Apr '01

07 Apr '01

someone (IIRC Gérard) had issues when starting the debugger when an exception occured. the setup was that the AeDebug registry key pointed to a shell script, which in turn, launched the real debugger (used to set up different context options, and such) however, what happens is: - the main program (the one generating the exception) tries to launch the debugger using the AeDebug - the process creation forks, and exec:s the debugger program - at the unix level, the debugged program starts, which runs the shell script, which then starts the debugger - at the windows level, since the shell script isn't a Wine process, the call fails (even if an Unix process is created) - the exception handler then reports the error in process creation and stops the main program, whereas the debugger has been started for this program either we decide that shell scripts shouldn't be used (easy solution) or we could do something like : - if the CreateProcess fails, then wait for a certain amount of time. If after that time the current process isn't currently debugged, then report the error. Otherwise assume what did happen is what has been described above comments are welcome A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard 07 Apr '01

07 Apr '01

eric pouech <eric.pouech(a)wanadoo.fr> writes: > using the Wine debugger (or any program using the debugging API) may > have some drawbacks. As the API is designed, it's not possible to > get control of the debugged program between its creation and its > entry point entering this makes very difficult to let the Wine > debugger trigger the expected features by poking the memory in the > debuggee. That's not exactly correct, the debugger can intercept the dll loads and break in the dll init code. Since with dll separation all Wine inits will be done inside dlls, the debugger should be able to intercept everything from the point we connect to the wineserver. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Nasty Wine/kernel bug, anyone?
by Ulrich Weigand 06 Apr '01

06 Apr '01

> If I were going to make more WAGs (Wild Assed guesses), > I'd hazard a guess that this was due to my Alsa sound system > (running on the AC97 codec on my Asus motherboard). > > I tried to walk the stack back, but didn't get very far > (after the first time of wrongly computing the hex offset > from a .s file, I gave off, stomped off to look > for a better disassembler and gave up). If you have the 'vmlinux' file, try objdump --disassemble vmlinux > My best guess is that we're coming through dentry_open > (xc012e7fe)/ chrdev_open (0xc012f66c) > /soundcore_open (0xc01bbf71). However, I wasn't > seeing a familiar EBP/EIP pattern, so I'm possibly just > pulling random symbols out of the air. Yes, this appears to the proper trace: c0108d7f system_call c012ea2c sys_open c012e732 filp_open c012e7fe dentry_open c012f66c chrdev_open c01bbf71 soundcore_open d0826a42 <module> d087ce3e <module> c0107aa4 __down_failed c010794f __down ........ schedule [I am assuming that you have 256MB main memory. Correct?] Now, the question is still, who is sleeping on that semaphore and why? >From the call trace, it would seem that some sound-related module is loaded, which does a down() on some semaphore in its open() routine. We even know which semaphore: cff267ac. (This does not help much, as this is would appear to be somewhere in kmalloc()ed memory ...) We can continue to track in two directions. First, we can try to locate the point within the Wine application where the open() syscall is performed. >From the trace we see that the system call instruction is located at 40303a24, and the stack pointer points to 405c6638. The system call itself is an open( 41610240, O_WRONLY|O_NDELAY ) [The stack pointer value is rather weird, I'd say ...] This particular open mode occurs in the Wine source only in dlls/winmm/wineoss/audio.c, which confirms the sound hypothesis. The next time you reproduce the bug, could you please add the output of /proc/<pid>/maps for the hanging Wine process? This way, we could further analyse these pointers to Wine user space ... The more promising way to track the problem, however, is to find out which module those d* addresses above reside in. If the modules are still loaded, the output of /proc/ksyms should at least give a hint. For a more refined symbol lookup, it is best to use the 'ksymoops' tool, which correlates the /proc/ksyms output with the ELF symbols read from the object modules themselves. To do so, write this: Call Trace: [<d0826a42>] [<d087ce3e>] to a file and pipe the file through ksymoops. In any case, this would seem to be clearly a bug in that sound module. I don't know, however, why only Wine would trigger that bug ... Bye, Ulrich -- Dr. Ulrich Weigand weigand(a)informatik.uni-erlangen.de

2 1

Re: [PATCH] Name Thread Exception support in Wine debugger
by eric pouech 06 Apr '01

06 Apr '01

James Hatheway wrote: > > Hi guys, > > As I mentioned in an earlier email to the Devel mailing list, I discovered the > application I am supporting started raising more exceptions than usual. These > turned out to be an undocumented signal to the MS VC6 debugger to name the > current thread. You can read more about this at: > http://www.vcdj.com/upload/free/features/vcdj/2001/03mar01/et0103/et0103.asp > or searching google.com or deja.com for "0x406D1388". This patch fixes > the WINE debugger to handle this exception, just like MS VC6 debugger does. something seems wrong in your patch... the szName field from the exception field is never copied from the debugged program space to the debugger space (only the address is) so, you should use ReadProcessMemory instead (something like ReadProcessMemory(pThread->name, sizeof(pThread->name), DEBUG_CurrThread->process->handle, pThreadName->szName); ) also, I don't like the fact that you put the #define in a public header file and the exception struct definition inside the file it would make more sense to me if both were either public or private (I'd go for private, since those values don't seem to be defined in Windows' standard headers) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

2 1

WWN
by eric pouech 06 Apr '01

06 Apr '01

for personal reasons, I will no longer be able to write the WWN (and I haven't in the last couple of weeks) so, if someone wishes to take the job over, I'd be happy to help him (her) to set it up A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

1 0

Re: [PATCH] deferred trace
by gerard patel 06 Apr '01

06 Apr '01

At 03:00 PM 14/03/2001 -0800, you wrote: <snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed. Expressed ? What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time. I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people. And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it. So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-) Gerard

2 1

Jump to page:

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