logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "peter.doornbosch" <peter.doornbo...@gmail.com>
Subject Re: Visual C++ Assertion failed when using LOG4CXX_DECODE_CHAR macro in statically linked MFC project
Date Thu, 27 Nov 2008 17:38:07 GMT
Hi Dale,

Thanks for your reply.

On 27 Nov , 2008, at 13:46 , Dale King wrote:

> I don't see anything wrong in what you showed. The problem is probably
> in code you have not shown. Based on the error you show it sounds more
> like you are doing something like delete string2;

Yes, that is what you might guess, but i can ensure you: i'm not ;-)

> Try making a a complete example source file that demonstrates the  
> problem.

I'll attach the relevant source files. I don't have them here, so that  
'll have to wait a few days.

Regards,
Peter

>
>
> On Mon, Nov 24, 2008 at 4:40 AM, Peter Doornbosch
> <peter.doornbosch@gmail.com> wrote:
>> Hi,
>>
>> First, let me say that log4cxx is great stuff.
>>
>> Unfortunately, i ran into a nasty issue.
>>
>> I use the following code fragment in a (very simple sample) MFC  
>> application:
>>
>>    CString string1("logfile.txt");
>>    LPCTSTR string2 = (LPCTSTR) string1;
>>    LOG4CXX_DECODE_CHAR(logstring, string2);
>>
>> This works fine, as long as i link the MFC libraries dynamically.
>> As soon as i switch over to statically linked, i get a failed  
>> assertion in
>> dbgheap.c (line 1252 i case you're interested ;-)).
>> It happens when the "logstring" goes out of scope.
>> The stacktrace shows the assert is triggered during a operator  
>> delete.
>>
>> The source code related to the failed assertion is this:
>>
>>       /*
>>         * If this ASSERT fails, a bad pointer has been passed in.  
>> It may be
>>         * totally bogus, or it may have been allocated from another  
>> heap.
>>         * The pointer MUST come from the 'local' heap.
>>         */
>>        _ASSERTE(_CrtIsValidHeapPointer(pUserData));
>>
>> While debugging, the pointer seems to point to a valid structure,  
>> so i guess
>> we've got a problem with allocation from "another heap".
>>
>> Any ideas?
>>
>> Switching to dynamically linked MFC libs is not an option for my real
>> project, as you might have guessed ;-).
>>
>> Thanks,
>> Peter.
>>
>>
>
>
>
> -- 
> Dale King


Mime
View raw message