> From: owner-openssl-us...@openssl.org On Behalf Of Tim Ward > Sent: Friday, 20 November, 2009 06:10
> > <snip: mk1mf with debug etc.> > It fails at the same point, the difference now being that the > libeay32.dll > function names are shown (rather than just addresses) in the stack > backtrace. I can't persuade VS2005 to show me the source > code, even though > it's apparently claiming to have picked up the .pdb file OK. > I see later you found this was a stale copy. > msvcr80d.dll!_setmode(int fh=0x00000003, int > mode=0x00008000) Line 58 + > 0x46 bytes C > libeay32.dll!_BIO_s_file() + 0x3dc bytes C > libeay32.dll!_BIO_ctrl() + 0xa0 bytes C > libeay32.dll!_ASN1_item_d2i_fp() + 0x54 bytes C > libeay32.dll!_d2i_PKCS12_fp() + 0x16 bytes C > test.exe!main(int argc=0x00000001, char * * > argv=0x003d4ee8) Line 32 + > 0xb bytes C > > Trying to follow that through the sources myself it doesn't > make any sense > to me - the BIO_s_file I've found, in bss_file.c, simply > returns a pointer, > it doesn't make any call to setmode or anything else. OK ... > looking at the Right. IIRC, that was first troublingly weird thing I saw also. > disassembly that's because there's something about the debug > information > that's confused VS2005, it's not actually BIO_s_file that's > being called, > it's several functions later, looks like file_ctrl. The other clue to this is BIO_s_file + 0x3dc i.e. offset almost 1K bytes, when BIO_s_file contains only one trivial statement. That's absurd, and implies some un-symbolified content. > Why doesn't the debugger know about it? I see later you found /Zi. > > (snip) > > And I'd be surprised if a lot use _fp routines. > > You certainly don't need them for SSL/TLS protocol, > > which I consider OpenSSL's strongest benefit. > > I'm wanting to do SSL/TLS. Which means I need a certificate > and a private > key. I've been given them in a PKCS#12 file. According to the > O'Reilly book > you read that by calling d2i_PKCS12_fp followed by > PKCS12_parse, which is It's arguably the simplest way, which I would guess is why the authors present it so. It appears to me the _bio approach would also work, and avoid the uplink problem; and I'm certain preconverting (extracting) a p12 to separate cert and key files and using those does work, because that's the way that was convenient for me. For that matter just choosing static rather than DLL should have avoided the problem, because MS tools discourage mixing runtimes within an EXE where they can't always do so for DLLs. But you had no reasonable way to guess that, since generally static versus DLL isn't supposed to make a serious difference like that. > exactly what the pkread.c sample does. I decided to start > with this bit in > the expectation that getting these two lines of code working > would be a > quick easy introduction to OpenSSL, certainly quicker and easier than > building the entire multithreaded asynchronous SSL server bit > and hooking > that into the rest of the application. > > What did I get wrong in the above chain of logic, and what > should I have > done instead, and how should I have known to do something > else instead? > I agree what you did is reasonable. It's unfortunate your first step landed in a sinkhole like this, when there is a fair bit of good ground nearby -- which sometimes you can't recognize until you've already been over it. But you did come here, to the group of people a priori most likely able to help; that's precisely why the list exists. It would certainly be better if everything worked, or at least every limitation was clearly documented, but this is a pretty big codebase (to solve a pretty big problem, that keeps changing) developed over a fairly long time (and sometimes crufted with legacy decisions that can't easily be ripped out) with apparently mostly volunteer labor. And people aren't perfect. Anyway, my sympathy for having this added, confusing and delaying problem on top of whatever real application one(s) you find. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
