Alex,
Thanks for the reply. I am going to wait for a pre built (RPM package) for wine-0.9.6 because if I compile I think I can introduce too many variables. Anyway, I am goig to report your sugestions with wine 0.9.5 and, ASAP, with wine-0.9.6.
Where can somebody download the application?
It is a commercial package. It can not be downloaded. Sorry
Is there a bug report for this application (bugs.winehq.org)?
No. If you guys wish I can do it (just going to wait for wine-0.9.6)
Just in case, are you installing on a VFAT partition, or on a ext2/ext3
partition? No windows involved. Just a ~.wine/drive_c inside a ext3 partition.
Have you tried running the installer under winedbg ("winedbg user.exe", then type "cont" at the debug prompt to pass control to the application)?
Good point!! I started right now, however the "winedbg user.exe" does not return any prompt. It seems freezed, waiting for something .... The processes running are: /usr/bin/wine-preloader /usr/bin/wine-pthread winedbg.exe user.exe /usr/bin/wineserver I also noticed I can do something like: WINEDUBUG=+all winebdg user.exe
Are you interested in the output of the above? Winedbg does not segfault. It freezes.
Your stack trace is missing the callback on where inside wine the fault occurred.
I am sending, attached, all the trace ..... it is not too big but .... I can notice there are some entries like: .... __wine_exception_handler ntdll.dll.1009 .....
------------------------- 8< ---------------------- 0009:trace:imports:import_dll --- RtlUnicodeToMultiByteSize ntdll.dll.639 = 0x7bea3670 0009:trace:imports:import_dll --- sprintf ntdll.dll.965 = 0x7bea5464 0009:trace:imports:import_dll --- sscanf ntdll.dll.967 = 0x7bea547c 0009:trace:imports:import_dll --- _strlwr ntdll.dll.912 = 0x7bea48e8 0009:trace:imports:import_dll --- _strupr ntdll.dll.914 = 0x7bea4918 --->> 0009:trace:imports:import_dll --- __wine_exception_handler ntdll.dll.1009 = 0x7beb17b0 0009:trace:imports:import_dll --- wine_server_call ntdll.dll.1013 = 0x7bed4f00 0009:trace:virtual:NtProtectVirtualMemory 0xffffffff 0x7fbf5000 00001000 00000080 0009:trace:virtual:VIRTUAL_SetProt 0x7fbf5000-0x7fbf5fff c-rWx 0009:trace:virtual:VIRTUAL_DumpView View: 0x7fb20000 - 0x7fc3ffff (system) 0009:trace:virtual:VIRTUAL_DumpView 0x7fb20000 - 0x7fc3ffff c-rWx 0009:trace:module:load_builtin_callback loaded user32.dll 0x7fd849f8 0x7fb20000 ------------------------- 8< ----------------------
Wine, in my opinion, is the next step for Linux to take over the desktop. It is the only tool that is missing. You guys are doing a great job. I am a wine user since 2000.
Regards. --------------------------------------------------------- Ulisses de Sousa Penna Analista Consultor - Banco do Brasil Fone: +55-61-3310-6320 Fax: +55-61-3310-6435 ---------------------------------------------------------
penna@bb.com.br wrote:
Alex,
Thanks for the reply. I am going to wait for a pre built (RPM package) for wine-0.9.6because if I compile I think I can introduce too many variables. Anyway, I am goig to report your sugestions with wine 0.9.5 and, ASAP, with wine-0.9.6.
That might be a problem. It would be better if you could compile the latest snapshot, or even better, the latest CVS, from scratch. This would enable you to test any patches I (or somebody else) might send to try and fix the problem.
Where can somebody download the application?
It is a commercial package. It can not be downloaded. Sorry
Is there a bug report for this application (bugs.winehq.org)?
No. If you guys wish I can do it (just going to wait for wine-0.9.6)
Please file the bug anyway. Then you can refer to the bug ID for future discussion.
I also noticed I can do something like: WINEDUBUG=+all winebdg user.exe
Are you interested in the output of the above? Winedbg does not segfault. It freezes.
It should be WINEDEBUG=+all, not WINEDUBUG... might be the problem.
Your stack trace is missing the callback on where inside wine the fault occurred.
I am sending, attached, all the trace ..... it is not too big but .... I can notice there are some entries like: .... __wine_exception_handler ntdll.dll.1009 .....
I meant the stack trace (the one that is supposed to be generated on an unhandled exception, and which contains information on which function called which one, all the way to the point where the exception occurred), not the debug trace (the one enabled by WINEDEBUG). However, the debug trace was useful by itself.
The last lines of your trace show the following:
0009:Call ntdll.RtlImageNtHeader(00000000) ret=7fce61da 0009: *killed* exit_code=0
This is bad - RtlImageNtHeader should be supplied a non-NULL pointer, and somebody passed it a NULL one instead. In addition, it seems there is an issue with the exception handling in RtlImageNtHeader
From dlls/ntdll/loader.c:
/*********************************************************************** * RtlImageNtHeader (NTDLL.@) */ PIMAGE_NT_HEADERS WINAPI RtlImageNtHeader(HMODULE hModule) { IMAGE_NT_HEADERS *ret;
__TRY { IMAGE_DOS_HEADER *dos = (IMAGE_DOS_HEADER *)hModule;
ret = NULL; if (dos->e_magic == IMAGE_DOS_SIGNATURE) { ret = (IMAGE_NT_HEADERS *)((char *)dos + dos->e_lfanew); if (ret->Signature != IMAGE_NT_SIGNATURE) ret = NULL; } } __EXCEPT_PAGE_FAULT { return NULL; } __ENDTRY return ret; }
The exception handler is supposed to return NULL in case of a page fault (such as trying to access a NULL pointer, as is your case). However, I think I saw a discussion somewhere in wine-devel that advised *not* to return from inside an __EXCEPT clause of an exception handler in Wine (most probably because __ENDTRY needs to run in order to clean up). If this is true, then RtlImageNtHeader is violating this rule. Your segmentation fault might be the expected result of a violation of the return rule. Could anybody in wine-devel speak up to confirm or refute this observation about exception handlers?
This, of course, does not address the actual issue of passing a NULL pointer to RtlImageNtHeader(). I could make a set of patches to add TRACEs to all functions with uses of RtlImageNtHeader(), but you need to be able to apply the patches for them to be actually of use.
Alex Villacís Lasso
Alex Villacís Lasso a_villacis@palosanto.com writes:
The exception handler is supposed to return NULL in case of a page fault (such as trying to access a NULL pointer, as is your case). However, I think I saw a discussion somewhere in wine-devel that advised *not* to return from inside an __EXCEPT clause of an exception handler in Wine (most probably because __ENDTRY needs to run in order to clean up). If this is true, then RtlImageNtHeader is violating this rule. Your segmentation fault might be the expected result of a violation of the return rule. Could anybody in wine-devel speak up to confirm or refute this observation about exception handlers?
Returning from inside the __TRY block is forbidden, but returning from the __EXCEPT block is fine.
-
Alex Villacís Lasso -
Alexandre Julliard -
penna＠bb.com.br