wine-devel April 2005

wine-devel@winehq.org

133 participants
273 discussions

Re: tools/widl
by Alexandre Julliard 25 Apr '05

25 Apr '05

Ge van Geldorp <gvg(a)reactos.com> writes: > + switch(var->type->type) > + { > + case RPC_FC_BYTE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_BYTE */\n", RPC_FC_BYTE); > + break; > + case RPC_FC_CHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_CHAR */\n", RPC_FC_CHAR); > + break; > + case RPC_FC_WCHAR: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_WCHAR */\n", RPC_FC_WCHAR); > + break; > + case RPC_FC_USHORT: > + case RPC_FC_SHORT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_USHORT */\n", RPC_FC_SHORT); > + break; > + case RPC_FC_ULONG: > + case RPC_FC_LONG: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_LONG */\n", RPC_FC_LONG); > + break; > + case RPC_FC_HYPER: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_HYPER */\n", RPC_FC_HYPER); > + break; > + case RPC_FC_IGNORE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_IGNORE */\n", RPC_FC_IGNORE); > + break; > + case RPC_FC_SMALL: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_SMALL */\n", RPC_FC_SMALL); > + break; > + case RPC_FC_FLOAT: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_FLOAT */\n", RPC_FC_FLOAT); > + break; > + case RPC_FC_DOUBLE: > + print_client("0x4e, /* FC_IN_PARAM_BASETYPE */\n"); > + print_client("0x%02x, /* FC_DOUBLE */\n", RPC_FC_DOUBLE); > + break; You should add some sort of get_fc_name() function instead of duplicating a big switch like that every time you want to print a name. > static void write_function_stubs(type_t *iface) > { > - func_t *cur = iface->funcs; > - char *handle_name = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + char *implicit_handle = get_attrp(iface->attrs, ATTR_IMPLICIT_HANDLE); > + int explitit_handle = is_attr(iface->attrs, ATTR_IMPLICIT_HANDLE); > + func_t *func = iface->funcs; > + var_t* var; Your patch would be a lot easier to review if you avoided renaming existing local variables. If you really think the names need to be changed please do it in a separate patch. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: Installing Mozilla
by Juan Lang 25 Apr '05

25 Apr '05

--- Uwe Bonnes <bon(a)elektron.ikp.physik.tu-darmstadt.de> wrote: > Is the Mozilla Installer Installshield or MSI based? Otherwise is it > open source? Perhaps an easier way to backtrace the problem? I believe it's open source. The crash was due to Mozilla attempting to write to a value that's exported by msvcrt.dll. It was declared in msvcrt's spec file, but never defined. Thus Mozilla was writing to a garbage pointer. It's been fixed in Wine. There's a separate issue that Mozilla probably isn't doing the right thing. It's overwriting a buffer it doesn't own and whose size is not documented, and it should be writing only four characters but is writing more. Now that Wine is fixed this is unlikely to cause anyone any trouble, but it's still not right. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

writejump purpose
by Robert Lunnon 25 Apr '05

25 Apr '05

In kthread.c there is this code that is only defined for I386 glibc, but the solaris port uses Solaris libc so the function does nothing. What is the purpose of this function and exactly what should the semantics be ? BOb static inline void writejump( const char *symbol, void *dest ) { #if defined(__GLIBC__) && defined(__i386__) unsigned char *addr = wine_dlsym( RTLD_NEXT, symbol, NULL, 0 ); if (!addr) return; /* write a relative jump at the function address */ mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC|PROT_WRITE); addr[0] = 0xe9; *(int *)(addr+1) = (unsigned char *)dest - (addr + 5); mprotect((void*)((unsigned int)addr & ~(getpagesize()-1)), 5, PROT_READ| PROT_EXEC); # ifdef HAVE_VALGRIND_MEMCHECK_H VALGRIND_DISCARD_TRANSLATIONS( addr, 5 ); # endif #endif /* __GLIBC__ && __i386__ */ }

2 1

Wine no longer compiles
by Ivan Gyurdiev 25 Apr '05

25 Apr '05

Haven't been able to compile cvs wine for the last few weeks. This is Fedora Rawhide with gcc4. Any suggestions? gcc -c -I. -I. -I../../../include -I../../../include -I../../../include/msvcrt -I./.. -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o file.o file.c In file included from ../../../include/winnt.h:27, from ../../../include/windef.h:204, from ../../../include/wine/test.h:25, from file.c:21: ../../../include/msvcrt/ctype.h:72: warning: conflicting types for built-in function ‘iswalnum’ ../../../include/msvcrt/ctype.h:73: warning: conflicting types for built-in function ‘iswalpha’ ../../../include/msvcrt/ctype.h:75: warning: conflicting types for built-in function ‘iswcntrl’ ../../../include/msvcrt/ctype.h:77: warning: conflicting types for built-in function ‘iswdigit’ ../../../include/msvcrt/ctype.h:78: warning: conflicting types for built-in function ‘iswgraph’ ../../../include/msvcrt/ctype.h:79: warning: conflicting types for built-in function ‘iswlower’ ../../../include/msvcrt/ctype.h:80: warning: conflicting types for built-in function ‘iswprint’ ../../../include/msvcrt/ctype.h:81: warning: conflicting types for built-in function ‘iswpunct’ ../../../include/msvcrt/ctype.h:82: warning: conflicting types for built-in function ‘iswspace’ ../../../include/msvcrt/ctype.h:83: warning: conflicting types for built-in function ‘iswupper’ ../../../include/msvcrt/ctype.h:84: warning: conflicting types for built-in function ‘iswxdigit’ ../../../include/msvcrt/ctype.h:85: warning: conflicting types for built-in function ‘towlower’ ../../../include/msvcrt/ctype.h:86: warning: conflicting types for built-in function ‘towupper’ ../../../include/msvcrt/io.h:179: error: ‘open’ aliased to external symbol ‘_open’ ../../../include/msvcrt/io.h:180: error: ‘sopen’ aliased to undefined symbol ‘_sopen’ ../../../include/msvcrt/process.h:129: error: ‘execl’ aliased to undefined symbol ‘_execl’ ../../../include/msvcrt/process.h:130: error: ‘execle’ aliased to undefined symbol ‘_execle’ ../../../include/msvcrt/process.h:131: error: ‘execlp’ aliased to undefined symbol ‘_execlp’ ../../../include/msvcrt/process.h:132: error: ‘execlpe’ aliased to undefined symbol ‘_execlpe’ ../../../include/msvcrt/process.h:133: error: ‘spawnl’ aliased to undefined symbol ‘_spawnl’ ../../../include/msvcrt/process.h:134: error: ‘spawnle’ aliased to undefined symbol ‘_spawnle’ ../../../include/msvcrt/process.h:135: error: ‘spawnlp’ aliased to undefined symbol ‘_spawnlp’ ../../../include/msvcrt/process.h:136: error: ‘spawnlpe’ aliased to undefined symbol ‘_spawnlpe’ -- Ivan Gyurdiev <ivg2(a)cornell.edu> Cornell University

2 1

PATCH: gcc4 alias fixes
by Marcus Meissner 24 Apr '05

24 Apr '05

Hi, This is the patch I use for gcc4.0 here. I am not really sure why this aliasing was introduced, but it will not work this way anymore. Ciao, Marcus diff -ruN -x CVS wine-20050419/include/msvcrt/conio.h marcus-wine-20050419/include/msvcrt/conio.h --- wine-20050419/include/msvcrt/conio.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/conio.h 2005-04-13 13:03:23.000000000 +0200 @@ -53,7 +53,7 @@ static inline unsigned short outpw(unsigned short i, unsigned short j) { return _outpw(i, j); } #endif -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int cprintf(const char*,...) __attribute__((alias("_cprintf"),format(printf,1,2))); extern int cscanf(const char*,...) __attribute__((alias("_cscanf"),format(scanf,1,2))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/io.h marcus-wine-20050419/include/msvcrt/io.h --- wine-20050419/include/msvcrt/io.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/io.h 2005-04-13 13:03:23.000000000 +0200 @@ -175,7 +175,7 @@ #endif static inline int write(int fd, const void* buf, unsigned int size) { return _write(fd, buf, size); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int open(const char*,int,...) __attribute__((alias("_open"))); extern int sopen(const char*,int,int,...) __attribute__((alias("_sopen"))); #else diff -ruN -x CVS wine-20050419/include/msvcrt/process.h marcus-wine-20050419/include/msvcrt/process.h --- wine-20050419/include/msvcrt/process.h 2004-07-19 13:07:44.000000000 +0200 +++ marcus-wine-20050419/include/msvcrt/process.h 2005-04-13 13:03:23.000000000 +0200 @@ -125,7 +125,7 @@ static inline int spawnvp(int flags, const char* name, const char* const* argv) { return _spawnvp(flags, name, argv); } static inline int spawnvpe(int flags, const char* name, const char* const* argv, const char* const* envv) { return _spawnvpe(flags, name, argv, envv); } -#ifdef __GNUC__ +#if defined(__GNUC__) && (__GNUC__ < 4) extern int execl(const char*,const char*,...) __attribute__((alias("_execl"))); extern int execle(const char*,const char*,...) __attribute__((alias("_execle"))); extern int execlp(const char*,const char*,...) __attribute__((alias("_execlp")));

2 1

Debugging with GDB [was: Re: World of Warcraft - crash in game]
by Alex Woods 24 Apr '05

24 Apr '05

On Thu, Mar 03, 2005 at 08:13:41AM +1100, Troy Rollo wrote: > On Thu, 3 Mar 2005 03:43, Alex Woods wrote: > > Unfortunately, I never got to try out this method properly. WoW has > > it's own dbghelp.dll that it checks on login and that contains different > > functions to wine's dbghelp. So I got stuck there, but it's not all bad > > news. > > In that case you may be able to use GDB directly on the executable (without > winedbg) and attach after the app has started with > "gdb /usr/local/bin/wine-pthread process-id". The major drawback of this is > that it cannot tell the difference between a first chance exception and a > last chance exception, so if the app uses exception handling you may end up > using GDB's "pass" command a lot. Well, after a long break, I'm back at trying to debug wine + WoW again. Somewhere alsa stopped working for me totally in wine (multilib problem I think). Now that it's working again, running the winmm and dsound tests I don't get any crashes, which I did before. I still get crashes in WoW though, with both OSS and ALSA, so I figure I'll try to get to the bottom of the common problems first before going back to see if ALSA is still a problem. I'm attaching to the process with gdb, but it's not catching things at the point where they go wrong. Typically I am just seeing a stack like this though: #0 0x56752a01 in ?? () I might be doing something wrong. It's been a long time since I used gdb for anything threaded, and never with NTLM. I've tried attaching to wine-pthread process and the wine-preloader process, with pretty much the same results. It's a real shame that +relay slows things down too much for be to be able to get to the point where a crash occurs. Does anyone have any suggestions as to how I might get a handle on where things are going wrong? How are exceptions caught by wine? A lot of the time WoW handles the error so can I work back from there? A lot of the time I get a report like this: This application has encountered a critical error: Not enough memory Program: C:\Program Files\World of Warcraft\WoW.exe File: C:\build\buildWoW\WoW\Source\WorldClient\MapMem.cpp Line: 589 WoWBuild: 4341 ------------------------------------------------------------------------------ ---------------------------------------- Stack Trace (Manual) ---------------------------------------- Address Frame Logical addr Module 0064F43E 55C0F970 0001:0024E43E C:\Program Files\World of Warcraft\WoW.exe 006500A5 55C0F988 0001:0024F0A5 C:\Program Files\World of Warcraft\WoW.exe 00651464 55C0F9A8 0001:00250464 C:\Program Files\World of Warcraft\WoW.exe 006B9F82 55C0F9D0 0001:002B8F82 C:\Program Files\World of Warcraft\WoW.exe 006D8FC6 55C0FAF4 0001:002D7FC6 C:\Program Files\World of Warcraft\WoW.exe 006B16AE 55C0FB20 0001:002B06AE C:\Program Files\World of Warcraft\WoW.exe 006B13B7 55C0FB3C 0001:002B03B7 C:\Program Files\World of Warcraft\WoW.exe 00689769 55C0FB4C 0001:00288769 C:\Program Files\World of Warcraft\WoW.exe 0048E70F 55C0FC00 0001:0008D70F C:\Program Files\World of Warcraft\WoW.exe 0048E293 55C0FC8C 0001:0008D293 C:\Program Files\World of Warcraft\WoW.exe 0076DDE1 55C0FCB0 0001:0036CDE1 C:\Program Files\World of Warcraft\WoW.exe 00762520 55C0FCD8 0001:00361520 C:\Program Files\World of Warcraft\WoW.exe 00760C72 55C0FCE4 0001:0035FC72 C:\Program Files\World of Warcraft\WoW.exe 0044224E 55C0FDAC 0001:0004124E C:\Program Files\World of Warcraft\WoW.exe 0041B8E6 55C0FDE4 0001:0001A8E6 C:\Program Files\World of Warcraft\WoW.exe 004175EA 55C0FE5C 0001:000165EA C:\Program Files\World of Warcraft\WoW.exe 00416D71 55C0FE74 0001:00015D71 C:\Program Files\World of Warcraft\WoW.exe 004044B0 55C0FF14 0001:000034B0 C:\Program Files\World of Warcraft\WoW.exe 55A58B9B 55C0FFF4 0001:00057B9B c:\windows\system\kernel32.dll Am I right in thinking that the logical address is the address I should use to look up the point it's failing in kernel32.dll? Using that and an asm dump of kernel32.dll.so places it in the error section of FindFirstFileExW I think: 57b82: 00 57b83: 89 04 24 mov %eax,(%esp) 57b86: e8 91 80 00 00 call 5fc1c <HeapFree> 57b8b: 83 ec 0c sub $0xc,%esp 57b8e: 8d 45 e8 lea 0xffffffe8(%ebp),%eax 57b91: 89 04 24 mov %eax,(%esp) 57b94: e8 37 21 fe ff call 39cd0 <RtlFreeUnicodeString> 57b99: 83 ec 04 sub $0x4,%esp 57b9c: c7 45 b0 ff ff ff ff movl $0xffffffff,0xffffffb0(%ebp) 57ba3: 8b 45 b0 mov 0xffffffb0(%ebp),%eax 57ba6: 8b 5d fc mov 0xfffffffc(%ebp),%ebx 57ba9: c9 leave 57baa: c2 18 00 ret $0x18 If I attach to wine-pthread and stick a breakpoint in that function, it does indeed get called right before WoW crashes out with the Out of memory error. I guess I'll work that back, seeing as I it's something I've found out during the course of writing this email, but any suggestions as to how I can make debugging easier would be truly appreciated, as would any answers to my questions. Cheers. -- Alex

2 2

Re: Installing Mozilla
by Juan Lang 24 Apr '05

24 Apr '05

Alex wrote: > I'm encountering a crash when trying to install Mozilla 1.7.7 under > wine. I am using a fresh CVS checkout, but I've tried older revisions > with the same result. So far, this evidence points to a bug in Mozilla rather than in Wine. It may very well be triggered by a bug in Wine.. > Here is a backtrace. It's falling over trying to write to > 0x99806858. Mozilla's passing an apparently invalid pointer to WideCharToMultiByte. Question is, where does this come from? Running with WINEDEBUG=nls may give a clue what string it's trying to convert, which may give some indication of the problem. Running with WINEDEBUG=relay will probably give a better clue, but be prepared for a huge log. But since the Mozilla source is available, you may be able to hunt it down more easily using that. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 3

Odd problem with process handles
by Robert Lunnon 24 Apr '05

24 Apr '05

I am having a problem with the attached segfault in ie6 I have attached a gdb backtrace and the last part of a relay dump. hModule is 0xffffffffe and gets dereferenced to find e_magic presumably from the psp. Obviously dereferencing 0xfffffffe is not good which raises an exception The exception is caught and appears to be ignored the first time it occurs but this seems unusual to me Can anyone shed light on this, is this normal or do I have a problem. What's going on here ? More info follows Bob ============================================================================ Starting program: /opt/cfw/wine/bin/wine iexplore Program received signal SIGSEGV, Segmentation fault. 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) (gdb) print dos $1 = (IMAGE_DOS_HEADER *) 0xfffffffe *** Aparrently in this code 1895 /*********************************************************************** 1896 * RtlImageNtHeader (NTDLL.@) 1897 */ 1898 PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule) 1899 { 1900 IMAGE_NT_HEADERS *ret; 1901 1902 __TRY 1903 { 1904 IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule; (gdb) 1905 1906 ret = NULL; 1907 if (dos->e_magic == IMAGE_DOS_SIGNATURE) 1908 { 1909 ret = (IMAGE_NT_HEADERS *)((char *)dos + dos->e_lfanew); 1910 if (ret->Signature != IMAGE_NT_SIGNATURE) ret = NULL; 1911 } 1912 } 1913 __EXCEPT(page_fault) 1914 { (gdb) 1915 return NULL; 1916 } 1917 __ENDTRY 1918 return ret; 1919 } **** Relay output 00b:Ret kernel32.LoadLibraryA() retval=00000000 ret=70c2429c 000b:Call kernel32.GetLastError() ret=70c242a9 000b:Ret kernel32.GetLastError() retval=0000007e ret=70c242a9 000b:Call kernel32.InterlockedExchange(70c2bd84,ffffffff) ret=70c242f0 000b:Ret kernel32.InterlockedExchange() retval=00000000 ret=70c242f0 000b:Call kernel32.GetProcAddress(ffffffff,70c24832 "ApphelpCheckShellObject") ret=70c24399 000b:Call ntdll.RtlInitAnsiString(7fd8dc18,70c24832 "ApphelpCheckShellObject") ret=7fe1e655 000b:Ret ntdll.RtlInitAnsiString() retval=7fd80018 ret=7fe1e655 000b:Call ntdll.LdrGetProcedureAddress(ffffffff,7fd8dc18,00000000,7fd8dc20) ret=7fe1e667 **** GDB Backtrace (gdb) bt #0 0xd1cbfb5f in RtlImageNtHeader (hModule=0xfffffffe) at loader.c:1907 #1 0xd1cc0018 in RtlImageDirectoryEntryToData (module=0xfffffffe, image=0, dir=0, size=0x7fd8db3c) at loader.c:2025 #2 0xd1cbdcd1 in LdrGetProcedureAddress (module=0xffffffff, name=0x7fd8dc18, ord=0, address=0x7fd8dc20) at loader.c:1154 #3 0xd1ccabcf in call_stdcall_function (func=0xd1cbdc9b <LdrGetProcedureAddress>, nb_args=4, args=0x7fd8dc08) at relay.c:521 #4 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2145511015) at relay.c:603 #5 0xd1d00025 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/ntdll.dll.so #6 0xd1ccab7d in call_stdcall_function (func=0x7fe1e62b <GetProcAddress>, nb_args=2, args=0x7fd8dce4) at relay.c:519 #7 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891779481) at relay.c:603 #8 0x7fec08dd in __wine_spec_forwards () from /opt/cfw/wine/lib/wine/kernel32.dll.so #9 0x70c23bd1 in ?? () #10 0x71191420 in ?? () #11 0x711819aa in ?? () #12 0x7118a3c9 in ?? () #13 0x71165a1c in ?? () #14 0x7fbab1af in WINPROC_wrapper () from /opt/cfw/wine/lib/wine/user32.dll.so #15 0x7fbab61d in WINPROC_CallWndProc (proc=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:418 #16 0x7fbb21a6 in CallWindowProcA (func=0x71165af5, hwnd=0x20022, msg=129, wParam=0, lParam=2144920548) at ../../windows/winproc.c:3202 #17 0x7fbea1f4 in call_window_proc (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, unicode=0, same_thread=1) at message.c:1521 #18 0x7fbec0cb in SendMessageTimeoutA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548, flags=0, timeout=4294967295, res_ptr=0x7fd8df78) at message.c:2376 #19 0x7fbec299 in SendMessageA (hwnd=0x20022, msg=129, wparam=0, lparam=2144920548) at message.c:2420 #20 0xd1ccabcf in call_stdcall_function (func=0x7fbec266 <SendMessageA>, nb_args=4, args=0x7fd8e040) at relay.c:521 #21 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=2137925787) at relay.c:603 #22 0x7fc3e3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #23 0xd1cca480 in call_cdecl_function (func=0x7f6e23b6 <X11DRV_CreateWindow>, nb_args=3, args=0x7fd8e1c0) at relay.c:462 #24 0xd1ccb2c2 in RELAY_CallFrom32 (ret_addr=2142912231) at relay.c:599 #25 0x7f71a3a1 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/x11drv.dll.so #26 0x7fba4554 in CreateWindowExA (exStyle=256, className=0x7fd8e538 "IEFrame", windowName=0x7fd8e74c "Microsoft Internet Explorer", style=47120384, x=-2147483648, y=-2147483648, width=-2147483648, height=-2147483648, parent=0x0, menu=0x94, instance=0x71160000, data=0x7ff39fb8) at ../../windows/win.c:1245 #27 0xd1ccae57 in call_stdcall_function (func=0x7fba43da <CreateWindowExA>, nb_args=12, args=0x7fd8e4fc) at relay.c:535 #28 0xd1ccb2e0 in RELAY_CallFrom32 (ret_addr=1891617362) at relay.c:603 #29 0x7fc3c851 in __wine_spec_exp_ordinals () from /opt/cfw/wine/lib/wine/user32.dll.so #30 0x71181c0e in ?? () #31 0x71181acf in ?? () #32 0x71181a86 in ?? () #33 0x7101f031 in ?? () #34 0x00401ecd in ?? () #35 0x00401f7d in ?? () #36 0x7fe2cbf2 in start_process (arg=0x0) at process.c:1044

2 1

Re: Odd problem with process handles
by Juan Lang 24 Apr '05

24 Apr '05

Hi Bob, > hModule is 0xffffffffe and gets dereferenced to find e_magic > presumably from the psp. Could you try the following really quick patch? I have no idea where the -1 value to GetProcAddress comes from, LoadLibraryA returned NULL. I'm also not sure whether the check belongs in here or in GetProcAddress. But this might let it get further for you. Index: dlls/ntdll/loader.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/loader.c,v retrieving revision 1.87 diff -u -r1.87 loader.c --- dlls/ntdll/loader.c 21 Mar 2005 10:52:26 -0000 1.87 +++ dlls/ntdll/loader.c 24 Apr 2005 17:09:39 -0000 @@ -2017,6 +2017,8 @@ const IMAGE_NT_HEADERS *nt; DWORD addr; + if ( module == (HMODULE)-1 ) + return NULL; if ((ULONG_PTR)module & 1) /* mapped as data file */ { module = (HMODULE)((ULONG_PTR)module & ~1); __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

More problems in ie6
by Robert Lunnon 24 Apr '05

24 Apr '05

In addition to the bad process handle I get intermittent crashes in IE6 which seems to be due to the creation of more than 8 threads or when a thread is ended (IE it occurs after thread 8 starts, then exits then another thread 8 starts (9th thread creation)) Thread 8 is the first thread that actually exited in the program. Are there any resource limits to per process thread creation in wine ? This seems to lead to a crash in temp_stacks +111 but temp stacks should not hold any executable code. The web site that seems to tickle this problem is www.gamedude.com.au Any Guesses anyone ? Bob

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
28
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 April 2005