wine 0.9.5 - segmentation fault with some apps

Alex Villací­s Lasso a_villacis at palosanto.com
Fri Jan 20 11:04:47 CST 2006


penna at bb.com.br wrote:

>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.
>
>  
>
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




More information about the wine-devel mailing list