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 Curt Arnold <ca...@apache.org> on 2007/07/01 08:34:22 UTC
Re: Race condition with FileAppender.
I have been unable to reproduce the problem on Ubuntu Linux 6.06-1
and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in
single processor or double processor mode. That is the glorious
thing about race conditions, the slightly little change might hide
them. Thanks for the output when you were seeing corruption, it at
least suggests that the problem isn't in the layout since all the
bogus characters appear between perfectly formatted messages. That
suggests that the problem is in the FileAppender or probably more
likely in the CharsetEncoder or CharsetDecoder.
I won't be able to work on it until Monday, however it would be
helpful to know if setting LOG4CXX_LOCALE_ENCODING_UTF8=1 (which will
replace the APR encoders/decoders with straight byte copies) or the
equivalent manual hack to src/charsetencoder.cpp and src/
charsetdecoder.cpp changes the behavior.
I've also run the helgrind tool from valgrind 2.2.0 and generated a
report of possible race conditions in the executed code, but I
haven't had time to review them yet.
Re: Race condition with FileAppender.
Posted by pe...@mu.org.
On Sun, Jul 01, 2007 at 03:49:44AM -0700, pete@mu.org wrote:
> Hmm., that's really odd. I can reproduce it on my two boxes with pent4
> with hyperthreading enabled, but I can't on my weenie single lapetop cpu.
I forgot to mention, that if I disable hyperthreading in the bios, then
the problem goes away. I don't know if that helps, but there you go.
Pete
>
> I'll try this and get back to you.
>
> LOG4CXX_LOCALE_ENCODING_UTF8=1
>
> Thanks,
>
> Pete
>
> On Sun, Jul 01, 2007 at 01:34:22AM -0500, Curt Arnold wrote:
> > I have been unable to reproduce the problem on Ubuntu Linux 6.06-1
> > and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in
> > single processor or double processor mode. That is the glorious
> > thing about race conditions, the slightly little change might hide
> > them. Thanks for the output when you were seeing corruption, it at
> > least suggests that the problem isn't in the layout since all the
> > bogus characters appear between perfectly formatted messages. That
> > suggests that the problem is in the FileAppender or probably more
> > likely in the CharsetEncoder or CharsetDecoder.
> >
> > I won't be able to work on it until Monday, however it would be
> > helpful to know if setting LOG4CXX_LOCALE_ENCODING_UTF8=1 (which will
> > replace the APR encoders/decoders with straight byte copies) or the
> > equivalent manual hack to src/charsetencoder.cpp and src/
> > charsetdecoder.cpp changes the behavior.
> >
> > I've also run the helgrind tool from valgrind 2.2.0 and generated a
> > report of possible race conditions in the executed code, but I
> > haven't had time to review them yet.
> >
> >
>
Re: Race condition with FileAppender.
Posted by pe...@mu.org.
Hmm., that's really odd. I can reproduce it on my two boxes with pent4
with hyperthreading enabled, but I can't on my weenie single lapetop cpu.
I'll try this and get back to you.
LOG4CXX_LOCALE_ENCODING_UTF8=1
Thanks,
Pete
On Sun, Jul 01, 2007 at 01:34:22AM -0500, Curt Arnold wrote:
> I have been unable to reproduce the problem on Ubuntu Linux 6.06-1
> and gcc 4.0.3 running under VMWare Fusion on Mac OS/X either in
> single processor or double processor mode. That is the glorious
> thing about race conditions, the slightly little change might hide
> them. Thanks for the output when you were seeing corruption, it at
> least suggests that the problem isn't in the layout since all the
> bogus characters appear between perfectly formatted messages. That
> suggests that the problem is in the FileAppender or probably more
> likely in the CharsetEncoder or CharsetDecoder.
>
> I won't be able to work on it until Monday, however it would be
> helpful to know if setting LOG4CXX_LOCALE_ENCODING_UTF8=1 (which will
> replace the APR encoders/decoders with straight byte copies) or the
> equivalent manual hack to src/charsetencoder.cpp and src/
> charsetdecoder.cpp changes the behavior.
>
> I've also run the helgrind tool from valgrind 2.2.0 and generated a
> report of possible race conditions in the executed code, but I
> haven't had time to review them yet.
>
>