-dev added, I think this is actually a bug > From: owner-openssl-us...@openssl.org On Behalf Of Michael Boman > Sent: Monday, 01 March, 2010 11:40 <re: crash in BIO_set_fp, on Windows, could it be faq#PROG2?>
> I am using OpenSSL 0.9.8l from http://www.slproweb.com/products/Win32OpenSSL.html > I link to these libraries for debugging: > C:\OpenSSL\lib\VC\ssleay32MTd.lib > C:\OpenSSL\lib\VC\libeay32MTd.lib > And these ones for release: > C:\OpenSSL\lib\VC\ssleay32MT.lib > C:\OpenSSL\lib\VC\libeay32MT.lib > I compile the program using the /MT (Release) and /MTd (Debug) flag > under C/C++ -> Code Generation Aside: all 4 pairs of .lib's in lib\VC (and one in lib) are exportlibs for the one pair of DLL's, which are actually /MD but use the applink mechanism, as mentioned in the FAQ, to get the right CRT -- assuming the EXE correctly compiles applink.c, and the code you referenced does. So this "should" work. And using the corresponding files from my (DLL) build of 0.9.8m it sort of does (see below), but using the SL distro I also get a crash. Stepping in the debugger I see code in SL that is similar but not identical. It appears to be built with VC++08 or possibly later, in particular for MSVCR90, while I use (elderly but still functional) VC++6.0 and MSVCRT[d], and the exit 0xC0000417 occurs in MSVCR90 appparently below _setmode. You didn't say what version of VC++ (and CRT) you are using. I believe this is a bug: bss_file.c file_ctrl() case for SET_FILE_PTR uses UP_fsetmode not UP_fsetmod so it doesn't uplink when it apparently should; instead uses direct _fileno and _setmode which faults in MSVCR90. On (old) VC++6.0/MSVCRT _fileno is inlined and works, and _setmode sets an error (EBADF) which is ignored, and the mode (bin/text) set by the app at fopen is apparently left intact (and works OK). Also looking in the same area: bss_file.c BIO_new_file() calls *ctrl BIO_C_SET_FILE_PTR with flags not including BIO_FP_TEXT, which sets binary even if the call said e.g. "w" or "wt"; on Windows this gives poor results if the output actually is text and needs \n=CRLF translation. Similarly BIO_{read,rw,write,append}_filename do SET_FILENAME with flags not containing TEXT. Explicitly calling BIO_ctrl SET_FILENAME with e.g. BIO_FP_WRITE|BIO_FP_TEXT does work. And BIO_new_fp() although prototyped as 'close_flag' actually honors TEXT as well, as documented. Some other things I noticed in working on this app: Personally I would do each formatting op once to a membio or string, and then duplicate the result to stdout and xmlOutput. That would also avoid this problem, since then the app wouldn't be using an fpbio for xmlOutput; everything else seems to work. And I wouldn't indent SOOOOO deeply. And I would handle long serials, as apps/x509.c does, since bigger than 32b are pretty common and (often spurious) negatives shouldn't be misleading. And officially WSAStartup should be once per process, although since about W2k as I recall repeats are benign. And unextended (insecure) client-initiated renegotiation is probably -- we hope! -- going to stop working soon. Logically I think it should work to compile the app /MD with a new(er) compiler that uses MSVCR90 and thus doesn't need uplink, or any supported mode(s) and static link (lib\VC\STATIC\various.lib) against a new-enough library to be compatible (old MSVCRT is not, it apparently doesn't have some _cookie stuff the SL build wants). But I'm not in a position to try those out for now. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
