You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Assaf Lavie <as...@gmail.com> on 2009/05/26 10:37:57 UTC
Caching LoggerPtr using local statics (the singleton pattern)
My program always crashes when I try to cache the LoggerPtr returned from
getLogger in a local static variable (i.e. singleton) like this:
LoggerPtr MyLogger()
{
static LoggerPtr singleton =
log4cxx::LogManager::getLogger("some.logger");
return singleton;
}
I assume this happens because of some APR related effect. Can someone please
shed light on this? Does this happen to you?
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Assaf Lavie <as...@gmail.com>.
Also, if assignment occurs separately from static initialization, then it
negates the whole reasoning for doing it with a static local variable (i.e.
that it only initializes once, and then returns the same object in
subsequent calls). So I would have to also check the static smart-pointer
for non-nullness to avoid calling getLogger over and over again (the very
thing I'm trying to avoid). And that's one more think that users of this
library can get wrong...
On Tue, May 26, 2009 at 5:54 PM, Assaf Lavie <as...@gmail.com> wrote:
> Thanks, I'll try.
> But wouldn't it also make sense to just initialize APR before anything else
> in the application (e.g. before configuring the log)?
> Because this business with default vs. one-param constructor is very easy
> to forget and get wrong (since both compile fine and it will only crash at
> runtime)...
>
>
> On Tue, May 26, 2009 at 4:20 PM, Curt Arnold <ca...@apache.org> wrote:
>
>> Try using the one parameter constructor for LoggerPtr, instead of the
>> default constructor and then an assignment:
>>
>> static LoggerPtr
>>> singleton(log4cxx::LogManager::getLogger("some.logger"));
>>>
>>>
>> There is a slight difference in order of events between the two. Using
>> the default constructor, it is
>>
>> 1. Construct singleton
>> 2. Call LogManager::getLogger()
>> 2a. initialize APR, etc
>> 3. Assign logger to singleton
>>
>> With the one parameter it is
>>
>> 1 Call LogManager::getLogger()
>> 1a initialize APR
>> 3. Construct singleton
>>
>> Since destruction events occur in reverse order, using the one-parameter
>> constructor results in APR being destroyed last.
>>
>>
>>
>> On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
>>
>> My program always crashes when I try to cache the LoggerPtr returned from
>>> getLogger in a local static variable (i.e. singleton) like this:
>>>
>>> LoggerPtr MyLogger()
>>> {
>>> static LoggerPtr singleton =
>>> log4cxx::LogManager::getLogger("some.logger");
>>> return singleton;
>>> }
>>>
>>>
>>> I assume this happens because of some APR related effect. Can someone
>>> please shed light on this? Does this happen to you?
>>>
>>
>>
>
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Assaf Lavie <as...@gmail.com>.
Thanks, I'll try.
But wouldn't it also make sense to just initialize APR before anything else
in the application (e.g. before configuring the log)?
Because this business with default vs. one-param constructor is very easy to
forget and get wrong (since both compile fine and it will only crash at
runtime)...
On Tue, May 26, 2009 at 4:20 PM, Curt Arnold <ca...@apache.org> wrote:
> Try using the one parameter constructor for LoggerPtr, instead of the
> default constructor and then an assignment:
>
> static LoggerPtr
>> singleton(log4cxx::LogManager::getLogger("some.logger"));
>>
>>
> There is a slight difference in order of events between the two. Using the
> default constructor, it is
>
> 1. Construct singleton
> 2. Call LogManager::getLogger()
> 2a. initialize APR, etc
> 3. Assign logger to singleton
>
> With the one parameter it is
>
> 1 Call LogManager::getLogger()
> 1a initialize APR
> 3. Construct singleton
>
> Since destruction events occur in reverse order, using the one-parameter
> constructor results in APR being destroyed last.
>
>
>
> On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
>
> My program always crashes when I try to cache the LoggerPtr returned from
>> getLogger in a local static variable (i.e. singleton) like this:
>>
>> LoggerPtr MyLogger()
>> {
>> static LoggerPtr singleton =
>> log4cxx::LogManager::getLogger("some.logger");
>> return singleton;
>> }
>>
>>
>> I assume this happens because of some APR related effect. Can someone
>> please shed light on this? Does this happen to you?
>>
>
>
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Rhosyn <rh...@purplescarab.com>.
Hi Balaji,
Static Singletons are problematic during system shutdown in multithreaded
systems.
This thread discusses that issue in a slightly different context with
log4cxx along with a slightly ugly but effective workaround (allocate the
object using new and store a raw pointer rather than a smart pointer in the
static variable):
http://mail-archives.apache.org/mod_mbox/logging-log4cxx-dev/200901.mbox/%3C4975157F.8070001@purplescarab.com%3E
Hth,
Rhosyn
On May 17, 2013 7:50 AM, "Balaji Babu" <ba...@gmail.com> wrote:
> Assaf Lavie <assaflavie <at> gmail.com> writes:
>
> >
> > I'm afraid this didn't help. Still crashes upon exit.Is caching the raw
> pointer instead of a smart-pointer a better solution?On Tue, May 26, 2009
> at
> 4:20 PM, Curt Arnold <carnold <at> apache.org> wrote:Try using the one
> parameter constructor for LoggerPtr, instead of the default constructor and
> then an assignment:
> > static LoggerPtr
> singleton(log4cxx::LogManager::getLogger("some.logger"));
> >
> >
> > There is a slight difference in order of events between the two. Using
> the default constructor, it is
> > 1. Construct singleton
> > 2. Call LogManager::getLogger()
> > 2a. initialize APR, etc
> > 3. Assign logger to singleton
> > With the one parameter it is
> > 1 Call LogManager::getLogger()
> > 1a initialize APR
> > 3. Construct singleton
> > Since destruction events occur in reverse order, using the one-parameter
> constructor results in APR being destroyed last.
> >
> >
> >
> > On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
> > My program always crashes when I try to cache the LoggerPtr returned from
> getLogger in a local static variable (i.e. singleton) like this:
> > LoggerPtr MyLogger()
> > {
> > static LoggerPtr singleton =
> log4cxx::LogManager::getLogger("some.logger");
> > return singleton;
> > }
> > I assume this happens because of some APR related effect. Can someone
> please shed light on this? Does this happen to you?
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> Hello Assaf Lavie,
> May I know whether you got the solution for this issue. Me too facing the
> same kind of issue in my application. The application is crashing at exit
> by
> pointing the apr_thread_mutex_destroy. It would be great help if I get the
> solution to resolve this issue.
>
> Thanks in advance.
> Balaji
>
>
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Balaji Babu <ba...@gmail.com>.
Assaf Lavie <assaflavie <at> gmail.com> writes:
>
> I'm afraid this didn't help. Still crashes upon exit.Is caching the raw
pointer instead of a smart-pointer a better solution?On Tue, May 26, 2009 at
4:20 PM, Curt Arnold <carnold <at> apache.org> wrote:Try using the one
parameter constructor for LoggerPtr, instead of the default constructor and
then an assignment:
> static LoggerPtr
singleton(log4cxx::LogManager::getLogger("some.logger"));
>
>
> There is a slight difference in order of events between the two. Using
the default constructor, it is
> 1. Construct singleton
> 2. Call LogManager::getLogger()
> 2a. initialize APR, etc
> 3. Assign logger to singleton
> With the one parameter it is
> 1 Call LogManager::getLogger()
> 1a initialize APR
> 3. Construct singleton
> Since destruction events occur in reverse order, using the one-parameter
constructor results in APR being destroyed last.
>
>
>
> On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
> My program always crashes when I try to cache the LoggerPtr returned from
getLogger in a local static variable (i.e. singleton) like this:
> LoggerPtr MyLogger()
> {
> static LoggerPtr singleton =
log4cxx::LogManager::getLogger("some.logger");
> return singleton;
> }
> I assume this happens because of some APR related effect. Can someone
please shed light on this? Does this happen to you?
>
>
>
>
>
>
>
>
>
Hello Assaf Lavie,
May I know whether you got the solution for this issue. Me too facing the
same kind of issue in my application. The application is crashing at exit by
pointing the apr_thread_mutex_destroy. It would be great help if I get the
solution to resolve this issue.
Thanks in advance.
Balaji
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Assaf Lavie <as...@gmail.com>.
I'm afraid this didn't help. Still crashes upon exit.Is caching the raw
pointer instead of a smart-pointer a better solution?
On Tue, May 26, 2009 at 4:20 PM, Curt Arnold <ca...@apache.org> wrote:
> Try using the one parameter constructor for LoggerPtr, instead of the
> default constructor and then an assignment:
>
> static LoggerPtr
>> singleton(log4cxx::LogManager::getLogger("some.logger"));
>>
>>
> There is a slight difference in order of events between the two. Using the
> default constructor, it is
>
> 1. Construct singleton
> 2. Call LogManager::getLogger()
> 2a. initialize APR, etc
> 3. Assign logger to singleton
>
> With the one parameter it is
>
> 1 Call LogManager::getLogger()
> 1a initialize APR
> 3. Construct singleton
>
> Since destruction events occur in reverse order, using the one-parameter
> constructor results in APR being destroyed last.
>
>
>
> On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
>
> My program always crashes when I try to cache the LoggerPtr returned from
>> getLogger in a local static variable (i.e. singleton) like this:
>>
>> LoggerPtr MyLogger()
>> {
>> static LoggerPtr singleton =
>> log4cxx::LogManager::getLogger("some.logger");
>> return singleton;
>> }
>>
>>
>> I assume this happens because of some APR related effect. Can someone
>> please shed light on this? Does this happen to you?
>>
>
>
Re: Caching LoggerPtr using local statics (the singleton pattern)
Posted by Curt Arnold <ca...@apache.org>.
Try using the one parameter constructor for LoggerPtr, instead of the
default constructor and then an assignment:
> static LoggerPtr
> singleton(log4cxx::LogManager::getLogger("some.logger"));
>
There is a slight difference in order of events between the two.
Using the default constructor, it is
1. Construct singleton
2. Call LogManager::getLogger()
2a. initialize APR, etc
3. Assign logger to singleton
With the one parameter it is
1 Call LogManager::getLogger()
1a initialize APR
3. Construct singleton
Since destruction events occur in reverse order, using the one-
parameter constructor results in APR being destroyed last.
On May 26, 2009, at 3:37 AM, Assaf Lavie wrote:
> My program always crashes when I try to cache the LoggerPtr returned
> from getLogger in a local static variable (i.e. singleton) like this:
>
> LoggerPtr MyLogger()
> {
> static LoggerPtr singleton =
> log4cxx::LogManager::getLogger("some.logger");
> return singleton;
> }
>
>
> I assume this happens because of some APR related effect. Can
> someone please shed light on this? Does this happen to you?