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 Mon, 01 Dec 2008 12:20:56 GMT
Hi Dale,

Please find attached my sample. It's just a sample MFC application
(generated with the mfc wizzard) that includes the code fragment i showed
earlier in CLog4cxxMFCApp.cpp.
If you compile this sample (which expects the log4cxx include files in
..\log4cxx-includes and the lib files in ..\log4cxx-lib) and run it, you'll
get the error. If you switch the project to dynamically linked (w.r.t. mfc
libraries), it works fine.

I didn't include the header and lib files, as that would make the zip rather
large.

Regards,
Peter.


2008/11/27 Dale King <dalewking@gmail.com>

> 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;
>
> Try making a a complete example source file that demonstrates the problem.
>
> 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