On 05/30/2012 11:45 PM, julien2412 wrote:
Quite recently, an interesting bt has been published by "bfoman" about this
bug (see https://bugs.freedesktop.org/attachment.cgi?id=62055) , here are
the top lines :
sal3!rtl_uString_newFromAscii+0x15
wininetbe1_uno!rtl::OUString::createFromAscii+0x40
wininetbe1_uno!WinInetBackend::WinInetBackend+0x1a0
Searching about "createFromAscii" in "wininetbackend" files, I found them in
"wininetbackend.cxx"
The only lines containing "createFromAscii" are :
157 rtl::OUString aProxyList =
rtl::OUString::createFromAscii( lpi->lpszProxy );
158 rtl::OUString aProxyBypassList =
rtl::OUString::createFromAscii( lpi->lpszProxyBypass );
Then I wonder what was "lpi" type and just read some lines above :
126 LPINTERNET_PROXY_INFO lpi = NULL;
Then searching about LPINTERNET_PROXY_INFO gave this url :
http://msdn.microsoft.com/en-us/library/windows/desktop/aa385148%28v=vs.85%29.aspx
"
typedef struct {
DWORD dwAccessType;
LPCTSTR lpszProxy;
LPCTSTR lpszProxyBypass;
} INTERNET_PROXY_INFO, * LPINTERNET_PROXY_INFO;
"
So kept on with attributes "lpszProxy" and "lpszProxyBypass" and its type
LPCTSTR, it gave this link :
http://msdn.microsoft.com/en-us/library/aa383751%28v=vs.85%29.aspx
"
This type is declared in WinNT.h as follows:
#ifdef UNICODE
typedef LPCWSTR LPCTSTR;
#else
typedef LPCSTR LPCTSTR;
#endif
"
On the same page, we can read :
for LPCSTR :
"
A pointer to a constant null-terminated string of 8-bit Windows (ANSI)
characters. For more information, see Character Sets Used By Fonts.
This type is declared in WinNT.h as follows:
typedef __nullterminated CONST CHAR *LPCSTR;
"
and for LPCWSTR :
"
A pointer to a constant null-terminated string of 16-bit Unicode characters.
For more information, see Character Sets Used By Fonts.
This type is declared in WinNT.h as follows:
typedef CONST WCHAR *LPCWSTR;
"
Then going back to createFromAscii to see if it could match with all this :
sal/inc/rtl/ustring.hxx : static OUString createFromAscii( const
sal_Char * value ) SAL_THROW(())
+
sal/inc/sal/types.h : typedef char sal_Char;
Now I wonder if it's ok to use createFromAscii to manage the attributes
"lpszProxy" and "lpszProxyBypass" ? (no ironical question here, just a
beginner question only :-))
wininetbackend.cxx explicitly calls the InternetQueryOptionA variant, so
the returned lpszProxy and lpszProxyBypass are char-sized strings, so
calling createFromAscii shall work. (Strictly speaking, it would cause
confusion if the strings contained characters outside ASCII, but it
would not lead to a crash within createFromAscii.) (And the version of
LPINTERNET_PROXY_INFO seen in wininetbackend.cxx also is the one using
LPCSTR, not LPCWSTR, as the call to createFromAscii would otherwise fail
to compile; and again, char/wchar_t mismatch would not explain a crash
within createFromAscii, anyway.)
The crash within createFromAscii is near the start of
rtl_uString_newFromAscii, from the crash information it looks like it
appears at dereferencing the first byte of pCharStr (aka pTempStr),
where pCharStr == 0x8fda7dbb. So it looks like InternetQueryOptionA
returns with the lpszProxy and/or lpszProxyBypass pointers pointing to
non-allocated memory.
What one notices is that neither of the two calls to
InternetQueryOptionA in WinInetBackend check the return value (the first
shall return with FALSE and GetLastError()==ERROR_INSUFFICIENT_BUFFER,
while the second shall return with TRUE). Maybe the call just fails and
returns FALSE?
(<http://msdn.microsoft.com/en-us/library/windows/desktop/aa385328%28v=vs.85%29.aspx>
"Option Flags" in the description of INTERNET_OPTION_PROXY states that
it is deprecated in favour of INTERNET_OPTION_PER_CONNECTION_OPTION.)
Stephan
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
