On Mar 28, 2006, at 3:14 PM, Wyles Eric - ewyles wrote:
Curt,
I have been able to reproduce this problem using the latest tar
ball at
http://littletux.homelinux.org/log4cxx/log4cxx-0.9.8.tar.gz
I used this because it was more convenient for me than trying to
figure
out how to grab the SVN HEAD. Is this ok?
On running against this latest snapshot, I have run onto at least 3
separate segmentation faults at different points in the code. I
suspect
there is some racing condition because it is unpredictable which of
these, if any, I will hit on a given run. I wonder if this is
something
to do with being on an SMP box.
How should I proceed? Separate bug reports for each problem that I
have
found? Where is the proper place to submit bug reports?
https://issues.apache.org:443/jira/browse/LOGCXX
This is a pretty big issue for me right now, so I will be
continuing to
test/debug and report my findings. So far, I have only been able to
capture one of these segmentation fault paths using valgrind. I am
including the output here. My platform is:
OS: RHEL 3
Compiler: gcc version 3.2.3 20030502
Processor Type: I don't have direct access to the machine, so I'm not
sure how to determine the processor type, but it is something of the
i686 variety.
Number of Processors: 2
Okay, wanted to know if this was something that we might see on Intel
linux or if it was just happening on a more obscure platform. Does
the problem show up with other versions of gcc like a gcc 3.3 or gcc
4.0?
Some additional info:
[ewyles@<host> src]$ uname -a
Linux <host> 2.4.21-27.0.2.ELsmp #1 SMP Wed Jan 12 23:35:44 EST 2005
i686 i686 i386 GNU/Linux
Here what I have from valgrind. I will continue trying to recreate as
many scenarios as possible through valgrind:
I'm not positive that I'm reading the log correctly, but it suggests
that the segmentation fault may be occurring after the APRInitializer
destructor is called. That should only occur after all log4cxx
related objects have been destroyed and segmentation faults would be
expected if that is not the case. Some compilers are known to not
correctly implement the destruction order in the specification.
On Mar 28, 2006, at 4:42 PM, Wyles Eric - ewyles wrote:
This is a really old mailing list posting, but could it be related
to my
problem in any way?
http://article.gmane.org/gmane.comp.apache.logging.log4cxx.user/46
After that message, all use of non-local static members was
eliminated EXCEPT Level::DEBUG, Level::INFO et all which were
publicly exposed and left for compatibility with existing programs
and ease of porting log4j client code. log4cxx does not use them,
but instead uses Level::getDebug(), Level::getInfo() et al. There
was a recent report of segmentation faults related to the destruction
of the Level::DEBUG and similar static members which were eliminated
when they were removed. Could you try your tests again and hack
level.h and level.cpp to remove those members.
