Logging + Thread = crash ?

[cdelmas]

Hi all,

I have a really curious problem using the Logging API. My code is the following :

- - - - - - - - - -

LoggerFactory factory;

Channel* file = factory.createChannel("FileChannel");

file->setProperty(FileChannel::PROP_PATH, "C:\tmp\appli.log");

file->setProperty(FileChannel::PROP_ROTATION, ":20");

file->setProperty(FileChannel::PROP_PURGEAGE, "10 minutes");

file->setProperty(PatternFormatter::PROP_TIMES, "local");

Channel* asyncFile = factory.createChannel("AsyncChannel");

dynamic_cast(asyncFile)->setChannel(file);

Logger::create("simple", asyncFile);


// somewhere else

Thread t;

t.start(Empty()); // Empty is a Runnable doing nothing

- - - - - - - -

That works fine in a single threaded environment. But when I try to create another thread, even if this thread doesn't access the logger, or worse, does nothing, the application crashes with the Windows code 3 ("The system cannot find the path specified."). If I suppress the line "t.start(Empty());", that works fine.
The problem seems to appear only with the AsyncChannel. I think it is a determinitic behavior, as I can reproduce it as much as I want (and it allways occurs).

A subsidiary question : can I log to an AsyncChannel from several threads without explicit synchronization ?

Thanks very much.

--

I really like Poco !

[peter]

That sounds strange. I mean, AsyncChannel uses internally already a thread for logging
(and it also implements Runnable).

I don't really see how starting yet another Thread could possible crash the application.

Could you repost your complete code on the mailing list (or update your previous entry)? The forum software requires you to write code inside the following tags (otherwise code gets swallowed):

~np~

Code: Select all

~/np~
[code]
int main(int argc, char** argv)
{
     std::cout < < "Hello, world!" < < std::endl;
     return 0;
}


~np~[/code]~/np~

Note: It will still hate the stream operator, thus the extra space in between.

And yes, AsyncChannel should be multi-threading safe.
Log messages are simple enqueued in a NotificationQueue
and then worked off one by one.

br

Peter

[cdelmas]

Hi all,

I have a really curious problem using the Logging API. My code is the following :

Code: Select all



void init() {
   LoggerFactory factory;
   Channel* file = factory.createChannel("FileChannel");
   file->setProperty(FileChannel::PROP_PATH, "C:\tmp\appli.log");
   file->setProperty(FileChannel::PROP_ROTATION, ":20");
   file->setProperty(FileChannel::PROP_PURGEAGE, "10 minutes");
   file->setProperty(PatternFormatter::PROP_TIMES, "local");
   Channel* asyncFile = factory.createChannel("AsyncChannel");
   dynamic_cast(asyncFile)->setChannel(file);
   Logger::create("simple", asyncFile);
}

int main() {
   init();
   Thread t;
   t.start(Empty()); //Empty::run() { for(;;); }
   Thread::sleep(10000);
}


That works fine in a single threaded environment. But when I try to create another thread, even if this thread doesn't access the logger, or worse, does nothing, the application crashes with the Windows code 3 ("The system cannot find the path specified."). If I suppress the line "t.start(Empty());", that works fine.
The problem seems to appear only with the AsyncChannel. I think it is a determinitic behavior, as I can reproduce it as much as I want (and it allways occurs).

Thanks very much.

===Edit=== : I use poco_1.2.8-ssl. I tried to use another thread lib, with the same result.

--

I really like Poco !

[cdelmas]

I have new informations : in debug mode, I have this report :

Debug error :
R6025 : pure virtual function call

I had a look at msdn, then read :

^No object has been instantiated to handle the pure virtual function call.
This error is caused by calling a virtual function in an abstract base class through a pointer which is created by a cast to the type of the derived class, but is actually a pointer to the base class. This can occur when casting from a void* to a pointer to a class when the void* was created during the construction of the base class.^

I think this could help.

[cdelmas]

I have new informations : in debug mode, I have this report :

Debug error :
R6025 : pure virtual function call

I had a look at msdn, then found :

^No object has been instantiated to handle the pure virtual function call.
This error is caused by calling a virtual function in an abstract base class through a pointer which is created by a cast to the type of the derived class, but is actually a pointer to the base class. This can occur when casting from a void* to a pointer to a class when the void* was created during the construction of the base class.^

I think this could help.

[guenter]

The problem is the way you create the Empty instance.
In your code, the Empty instance will be deleted immediately after the

Code: Select all


t.start(Empty());


line is completed. Remember that temporary objects in C++ are destroyed immediately after the statement where they have been created is done. This means that the Empty object will no longer exist once the new threat gets to call its run() method.

Solution:

Code: Select all


Empty empty;
t.start(empty);


Here, the Empty instance will be around until the end of the enclosing block (which is the end of main()), and not just until the start() call is done.