You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-dev@logging.apache.org by Tommi Mäkitalo <to...@epgmbh.de> on 2004/12/17 00:12:59 UTC
empty lines between log-messages
Hi again,
why there is a empty line between each log-message? Here is how the output of
example/trivia looks like:
tommi@nurmi:~/Projekte/logging-log4cxx/examples> ./trivial
0 [-1768770976] root trivial context - debug message
0 [-1768770976] root trivial context - info message
0 [-1768770976] root trivial context - warn message
0 [-1768770976] root trivial context - error message
0 [-1768770976] root trivial context - fatal message
tommi@nurmi:~/Projekte/logging-log4cxx/examples>
Another funny thing is, that the thread-id is negative.
Tommi
Re: empty lines between log-messages
Posted by Tommi Mäkitalo <to...@epgmbh.de>.
Am Freitag, 17. Dezember 2004 01:07 schrieb Curt Arnold:
> On Dec 16, 2004, at 5:12 PM, Tommi Mäkitalo wrote:
> > Hi again,
> >
> > why there is a empty line between each log-message? Here is how the
> > output of
> > example/trivia looks like:
>
> Looks like I probably added a \n that didn't need to be there. This
> should cause a test failure when I'm able to run more than a few tests
> without crashing.
>
I found the \n (or better std::endl). Here is the patch.
Tommi
Re: empty lines between log-messages
Posted by Curt Arnold <ca...@houston.rr.com>.
On Dec 16, 2004, at 5:12 PM, Tommi Mäkitalo wrote:
> Hi again,
>
> why there is a empty line between each log-message? Here is how the
> output of
> example/trivia looks like:
Looks like I probably added a \n that didn't need to be there. This
should cause a test failure when I'm able to run more than a few tests
without crashing.
>
On Dec 16, 2004, at 5:12 PM, Tommi Mäkitalo wrote:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182914822752 (LWP 19695)]
0x0000002a960af733 in std::operator<< <wchar_t,
std::char_traits<wchar_t>,
std::allocator<wchar_t> > ()
from /usr/lib64/libstdc++.so.5
A segfault in a std::basic_string() default constructor is a sign that
something went seriously wrong sometime before that call. You can't
really figure it out from the call site. Hopefully it will go away
after I start knocking off problems in the test suite.
That anything works at the moment is just a coincidence. Only when I
get the test suite passing all tests will I concern myself with new
implementation problem reports. The primary reason that I committed
before passing all the tests was to get feedback on the API. Obviously
I would now like to get the thing stable again, but it isn't there yet.