For those that may see this problem in the future, here is what I have learned so far:
The InitializeCriticalSecion initializes a mutex at ( 0x00af2a34 ) then attempts to EnterCriticalSection on the same mutex passing in an address of ( 0x00af2a2c )
The important thing is the &mutex of both calls is diffenrent
This is pure speculation, but I think this may be a multiple virtual Inheritance/lack of cross cast Issue
The Object vtable on this in FRAME 2 looks bogus.
class LOG4CXX_EXPORT AppenderSkeleton :
public virtual Appender,
public virtual helpers::ObjectImplFRAME 2
void ObjectImpl::lock() const
{
cs.lock();
}FRAME 3
class synchronized
{
public:
synchronized(const Object * object) : object(object)
{ object->lock(); }
FRAME 4
void FileAppender::setFile(const String& fileName, bool append,
bool bufferedIO, int bufferSize)
{
synchronized sync(this);I'm going to try to go to CVS Head
Curt Arnold wrote:
On Jan 6, 2005, at 12:32 PM, Kevin Tew wrote:
I've wrote a example app below that illustrates the problem. Any suggestions? Kevin ( listman)
The threading code in the current CVS is now based on Apache Portable Runtime, so any threading related bug in 0.9.7 has at least moved. I converted your code to run using the current CVS (which is only necessary since you were doing a lot of explicit configuration). I didn't get an exception in the construction of the RollingFileAppender (RFA) on XP, but did get a heap corruption warning at program exit similar to what I've seen on NDC::pop and will investigate.
While investigate this, I started moving some of the log4j RollingFileAppender tests over to log4cxx and eventually realized that the current log4cxx RFA is considerably out of sync with the current log4j. I filed a bug report (LOG4CXX-52 for the enhancement and committed header files derived from log4j 1.3's RFA in include/log4cxx/rolling. However, I wouldn't expect to be able to fill in the implementation for a while.
Here are is a patch to convert your sample app to use the current CVS version.
1c1
< / testing.cpp : Defines the entry point for the console application.
---
> // testing.cpp : Defines the entry point for the console application.
4d3
< #include "stdafx.h"
7a7
> #include <log4cxx/logstring.h>
11a12
> #include <log4cxx/file.h>
17c18
< int _tmain(int argc, _TCHAR* argv[])
---
> int main(int argc, char* argv[])
37c38
< static const char *layoutPattern = "%c %p %d{%Y-%b-%d %H:%M:%S} %m";
---
> static const log4cxx::logchar* layoutPattern = LOG4CXX_STR("%c %p %d{%Y-%b-%d %H:%M:%S} %m");
39c40
< fCBLogger->addAppender( new log4cxx::ConsoleAppender( new log4cxx::PatternLayout( layoutPattern ), "system.out" ) );
---
> fCBLogger->addAppender( new log4cxx::ConsoleAppender( new log4cxx::PatternLayout( layoutPattern ), LOG4CXX_STR("system.out") ) );
43c44
< fCBLogger->addAppender( new log4cxx::ConsoleAppender( new log4cxx::PatternLayout( layoutPattern ), "system.err" ) );
---
> fCBLogger->addAppender( new log4cxx::ConsoleAppender( new log4cxx::PatternLayout( layoutPattern ), LOG4CXX_STR("system.err") ) );
48c49
< NTEventLogAppenderPtr ntEventLogAppender = new log4cxx::nt::NTEventLogAppender( "localhost", "Application", "cbIntegrate", new log4cxx::PatternLayout( layoutPattern ) );
---
> NTEventLogAppenderPtr ntEventLogAppender = new log4cxx::nt::NTEventLogAppender( LOG4CXX_STR("localhost"), LOG4CXX_STR("Application"), LOG4CXX_STR("cbIntegrate"), new log4cxx::PatternLayout( layoutPattern ) );
54c55
< RollingFileAppenderPtr rollingFileAppender = new log4cxx::RollingFileAppender( new log4cxx::PatternLayout( layoutPattern ), "cbLog.log" );
---
> RollingFileAppenderPtr rollingFileAppender = new log4cxx::RollingFileAppender( new log4cxx::PatternLayout( layoutPattern ), log4cxx::File(LOG4CXX_STR("cbLog.log")) );
56c57
< rollingFileAppender->setMaxFileSize( "10MB" );
---
> rollingFileAppender->setMaxFileSize( LOG4CXX_STR("10MB") );
