Re: HexEncoder causes unhandled exception

[Wei Dai]

Another thread closed. :-)

----- Original Message -----

From: Søren Dreijer

To: Wei Dai

Sent: Saturday, December 23, 2006 3:52 PM

Subject: RE: HexEncoder causes unhandled exception

Hi Wei,
 
Just wanted to let you know that I don't have any problems with HexEncoder and StringSink in the latest version of Crypto++. Good work :]

Soren

---

From: wei...@weidai.com
To: hal...@hotmail.com
Subject: Re: HexEncoder causes unhandled exception
Date: Tue, 12 Dec 2006 14:51:53 +0800

Hi, I tried to look into this, but I'm able to use HexEncoder from a managed DLL without problems. From you stack, it looks like the separator and terminator parameters to HexEncoder::HexEncoder are invalid. What does the code calling creating HexEncoder look like?

----- Original Message -----

From: Søren Dreijer

To: crypto...@eskimo.com

Sent: Monday, May 29, 2006 4:27 AM

Subject: HexEncoder causes unhandled exception

And I'm back.
 
It seems there is a problem with HexEncoder. Whenever I try to create an instance of the class I get an unhandled exception. I'm using version 5.2.3 of the library.
 
Below is shown a stack trace:
 
cryptopp.dll!memcpy(unsigned char * dst=0x00000000, unsigned char * src=0x0012f6c4, unsigned long count=3435973836)  Line 188 Asm
cryptopp.dll!CryptoPP::SecBlock<unsigned char,CryptoPP::AllocatorWithCleanup<unsigned char> >::Assign(const unsigned char * t=0x0012f6c4, unsigned int len=0)  Line 280 + 0xd bytes C++
cryptopp.dll!CryptoPP::Grouper::IsolatedInitialize(const CryptoPP::NameValuePairs & parameters={...})  Line 201 C++
cryptopp.dll!CryptoPP::Filter::Initialize(const CryptoPP::NameValuePairs & parameters={...}, int propagation=-2)  Line 65 C++
cryptopp.dll!CryptoPP::Filter::PropagateInitialize(const CryptoPP::NameValuePairs & parameters={...}, int propagation=-1)  Line 99 + 0x15 bytes C++
cryptopp.dll!CryptoPP::Filter::Initialize(const CryptoPP::NameValuePairs & parameters={...}, int propagation=-1)  Line 65 + 0xf bytes C++
cryptopp.dll!CryptoPP::HexEncoder::IsolatedInitialize(const CryptoPP::NameValuePairs & parameters={...})  Line 19 + 0x69 bytes C++
cryptopp.dll!CryptoPP::HexEncoder::HexEncoder(CryptoPP::BufferedTransformation * attachment=0x00000000, bool uppercase=true, int outputGroupSize=0, const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & separator="ÌÌÌÌ:", const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & terminator="ÌÌÌÌ")  Line 15 + 0x69 bytes C++

If anyone is still alive in this mailing list, please tell me what's going on here!

---

Express yourself instantly with MSN Messenger! MSN Messenger

---

Windows Live Spaces is here! It’s easy to create your own personal Web site. Check it out!

[dreijer]

Actually, the problem has *not* gone away. It works in debug mode, but
once I run the application in release mode I get an unhandled exception
when using HexEncoder with StringSink.

I suspect this problem might have something to do with the following
problem since both examples crash when std::strings are used to encode
an RSA key:
http://groups.google.com/group/cryptopp-users/browse_thread/thread/474c7d17af2152b2/c7f4a26262a84c7c#c7f4a26262a84c7c

Soren

[Wei Dai]

This is really strange, and I can't think of an explanation except that
something is wrong with your machine's configuration. Maybe your include
paths are messed up, or your system header files have been modified, or
you're linking with an old system library. Can you recompiling the same code
on a different machine? If not, or if the same thing occurs on another
machine, please send me a .zip file of your entire project and I'll take a
look.

----- Original Message -----
From: "dreijer" <ad...@blacksmith-studios.dk>
To: "Crypto++ Users" <cryptop...@googlegroups.com>
Sent: Tuesday, December 26, 2006 9:09 AM
Subject: Re: HexEncoder causes unhandled exception

>

[dreijer]

This has happened on multiple machines. I will try and run it in one of
my virtual machines and see if the same problem occurs.

[dreijer]

Okay, so I have installed VS2005 Professional on a clean Windows XP SP2
machine. I have not yet installed VS2005 SP1 as it takes forever.

The build of the library still fails due to the custom build rule on
adhoc.cpp.proto. I get the following output:

------ Rebuild All started: Project: cryptlib, Configuration: Debug
Win32 ------
Deleting intermediate and output files for project 'cryptlib',
configuration 'Debug|Win32'
Performing Custom Build Step
The system cannot find the path specified.
Project : error PRJ0019: A tool returned an error code from "Performing
Custom Build Step"
Build log was saved at "file://c:\Documents and Settings\Søren
Dreijer\Desktop\cryptopp54\Win32\cryptlib\Debug\BuildLog.htm"
cryptlib - 1 error(s), 0 warning(s)

Anyway, I first tested Crypto++ with static linking. I succeeded in
using the HexEncoder when generating code with both the /MTd and /MDd
flags. It turns out this works on my own computer as well.

Previously, I've been using the DLL rather than the static library in
my own applications. Before I even got to test the behavior of the DLL
today, however, I experienced another problem. When the application
uses the DLL and it executes the first call to the library, I get the
following exception:

Crypto++ was not able to obtain new and delete function pointers.
First-chance exception at 0x7c812a5b in Cryptopp Test.exe: Microsoft
C++ exception: int at memory location 0x0012f190..

I've had this appear occasionally onm VS2003 too, but it seemed to go
away. The library and the application are using the same runtime
library (/MTd) and the same calling convention (__cdecl (/Gd))

It appears the dlltest project included in the library uses the
__stdcall (/Gz) calling convention. I tried doing the same in my own
application, but I still got the exception.

Hmm..

[Jeffrey Walton]

Hi Soren,

> Anyway, I first tested Crypto++ with static linking. I succeeded in
> using the HexEncoder when generating code with both the /MTd and /MDd
> flags. It turns out this works on my own computer as well.

Here's what I know about random errors which disappear when moving
between static and dynamic linking:
I once had a project with the following settings:
Crypto++ (static linking) (version 4 something, or early 5)
MFC (dynamic linking)
Dinkumware STL(static linking into a library backed by a DLL)

The project was MDI, so I was having big time problems with the
Document Iterator and Dinkumware 's library. I got it to compile
eventually with some warnings about mixing and match (symbol xxx
already defined, use 'no default lib'...).

If the Release EXE was run from a Network Drive, I would get random
crashes in Ordinal 6758. See
http://groups.google.com/group/microsoft.public.vc.mfc/tree/browse_frm/thread/cbad8aa7d0ad6b13/22a323ded8787db3

It's not a solution, just a heads up.
Jeff

[Wei Dai]

dreijer wrote:
> Crypto++ was not able to obtain new and delete function pointers.
> First-chance exception at 0x7c812a5b in Cryptopp Test.exe: Microsoft
> C++ exception: int at memory location 0x0012f190..

Here is the section titled "DLL Memory Management" from Readme.txt:

Because it's possible for the Crypto++ DLL to delete objects allocated
by the calling application, they must use the same C++ memory heap.
Three
methods are provided to achieve this.
1. The calling application can tell Crypto++ what heap to use. This
method
is required when the calling application uses a non-standard heap.
2. Crypto++ can tell the calling application what heap to use. This
method
is required when the calling application uses a statically linked
C++ Run
Time Library. (Method 1 does not work in this case because the
Crypto++ DLL
is initialized before the calling application's heap is
initialized.)
3. Crypto++ can automatically use the heap provided by the calling
application's
dynamically linked C++ Run Time Library. The calling application
must
make sure that the dynamically linked C++ Run Time Library is
initialized
before Crypto++ is loaded. (At this time it is not clear if it is
possible
to control the order in which DLLs are initialized on Windows 9x
machines,
so it might be best to avoid using this method.)

When Crypto++ attaches to a new process, it searches all modules loaded

into the process space for exported functions
"GetNewAndDeleteForCryptoPP"
and "SetNewAndDeleteFromCryptoPP". If one of these functions is found,
Crypto++ uses methods 1 or 2, respectively, by calling the function.
Otherwise, method 3 is used.

(end quote)

It looks like method 3 failed. You can either try to figure out why, or
use one of the other methods. Look at dlltest.cpp for sample code of
method 2. Or just use the static library.

[dreijer]

Yeah, I already read the readme file and it was quite obvious what was
wrong. The real problem, however, is why :]

For now I'll just use the static library. I don't need the FIPS stuff.