This sounds like a problem I've run into before. Remember that a FILE *
structure uses memory malloc'd from a heap, and that Windows DLLs have their
own heaps, distinct from the main app. As such, you cannot set up a pointer
in one space and then use it with malloc/realloc in the other space. Also,
you cannot statically initialize a pointer with "FILE *blah = stdout;"
because "stdout" is not a simple constant; it's value can only be set at
runtime since it is an import from the C runtime DLL. The reason that you
see two different addresses right now is that the value you see is really
the address of an address, one is a pointer to stdout living in the DLL's
space, and the other is a pointer to stdout residing in app space. Assuming
that you have properly #include'd <stdio.h> the compiler should have
generated the proper code to reference the imported value.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Kudlawiec
> Sent: Thursday, November 09, 2000 10:30 AM
> To: ZZ) LISTSERV: Openssl-Dev (E-mail)
> Subject: stdout problem on NT only - our fix
>
>
> We discovered a problem running openssl with our application on
> WinNT4.0 and
> using Visual C++ 6.0.
>
> When we run our application, it makes a call to SSL_write, then an access
> violation occurs executing fwrite within the function file_write
> of openSSL.
>
> Upon closer inspection, we found the culprit to be stdout. From within our
> application, while initializing openSSL, b->ptr (b is type BIO) is set to
> stdout. Just before the crash within openSSL, b->ptr is still pointing to
> that
> address; however, if a variable is set within openSSL to stdout, that
> variable
> points to a different address.
>
> In other words: If a variable is set to stdout in our application, and a
> variable is set to stdout within openSSL, the two point to different
> addresses
> in NT--in Unix, both point to the same address. In NT, if an
> attempt is made
> to
> use the stdout address set in the calling from application within
> openSSL, a
> crash occurs.
>
> An earlier message on the listserv indicated a similar problem (see "App
> crash
> on NT"); the solution suggested using the multithreaded dll version of the
> run-time libraries. We verified that the correct libraries are
> indeed being
> used. Someone else suggested that the library containing the standard
> implentation for a console app was missing; we verified that it
> was included
> within our application as well as openssl.
>
> The solution we developed is to create a function within openssl
> that simply
> returns the pointer to stdout. This way, the pointer to stdout is
> correct in
> whatever environment it resides. Our application can then use this to set
> b->ptr to the correct address of stdout.
>
> We made the following changes to the NT version:
> 1) Within
> openssl-0.9.4\inc32\openssl\ssl.h
> openssl-0.9.4\ssl\ssl.h
> the following prototype was added:
>
> FILE *SSLGetSSLstdout(void);
>
> 2) Within
> openssl-0.9.4\ssl\ssl_lib.c
> the following function was added:
>
> FILE *SSLGetSSLstdout(void)
> {
> return (stdout);
> }
>
> 3) Within
> openssl-0.9.4\ms\ssleay32.def
> the following line was added under "EXPORTS":
>
> SSLGetSSLstdout
>
> If we are missing something, please let us know. Thanks!
>
> Paul Kudlawiec
> Software Engineer
> [EMAIL PROTECTED]
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
