logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale King" <dalewk...@gmail.com>
Subject Re: Visual C++ Assertion failed when using LOG4CXX_DECODE_CHAR macro in statically linked MFC project
Date Thu, 27 Nov 2008 19:57:21 GMT
Don't just attach your existing problem files. Create a *S*hort
*S*elf-*C*ontained
*C*ompilable *E*xample. See http://mindprod.com/jgloss/sscce.html.

Usually the process of creating a SSCCE, will help you discover the problem
yourself.

On Thu, Nov 27, 2008 at 12:38 PM, peter.doornbosch <
peter.doornbosch@gmail.com> wrote:

> 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
>>
>
>


-- 
Dale King

Mime
View raw message