Author: carnold
Date: Sun Aug 23 23:24:37 2009
New Revision: 807031
URL: http://svn.apache.org/viewvc?rev=807031&view=rev
Log:
LOGCXX-340: Transcoder::encodeCharsetName bungles encoding
Modified:
logging/log4cxx/trunk/src/changes/changes.xml
logging/log4cxx/trunk/src/main/cpp/transcoder.cpp
logging/log4cxx/trunk/src/test/cpp/helpers/transcodertestcase.cpp
Modified: logging/log4cxx/trunk/src/changes/changes.xml
URL: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/changes/changes.xml?rev=807031&r1=807030&r2=807031&view=diff
==============================================================================
--- logging/log4cxx/trunk/src/changes/changes.xml (original)
+++ logging/log4cxx/trunk/src/changes/changes.xml Sun Aug 23 23:24:37 2009
@@ -22,7 +22,7 @@
<title>Apache log4cxx</title>
</properties>
<body>
-<release version="0.11.0" date="2008-XX-XX" description="Maintenance release">
+<release version="0.11.0" date="2009-XX-XX" description="Maintenance release">
<action issue="LOGCXX-249">Console appender crashes if layout is not set</action>
<action issue="LOGCXX-262">socketappendertestcase and xmlsocketappendertestcase not
run</action>
<action issue="LOGCXX-263">Bad link to log4cxx-dev archive</action>
@@ -52,6 +52,7 @@
<action issue="LOGCXX-300">ODBCAppender connection settings broken (or just have changed).</action>
<action issue="LOGCXX-303">DOMConfigurator does not set ErrorHandler.</action>
<action issue="LOGCXX-304">BasicConfigurator::configure results in writer not set warning.</action>
+<action issue="LOGCXX-340">Transcoder::encodeCharsetName bungles encoding</action>
</release>
<release version="0.10.0" date="2008-04-03" description="First Apache release">
<action issue="LOGCXX-2">logger.h includes config.h</action>
Modified: logging/log4cxx/trunk/src/main/cpp/transcoder.cpp
URL: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/main/cpp/transcoder.cpp?rev=807031&r1=807030&r2=807031&view=diff
==============================================================================
--- logging/log4cxx/trunk/src/main/cpp/transcoder.cpp (original)
+++ logging/log4cxx/trunk/src/main/cpp/transcoder.cpp Sun Aug 23 23:24:37 2009
@@ -523,13 +523,13 @@
'@', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L',
'M', 'N', 'O',
'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z', '[', '\\',
']', '^', '_',
'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l',
'm', 'n', 'o',
- 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '{', '|',
'}', '~', ' ' };
+ 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', '{', '|',
'}', '~' };
std::string out;
for(LogString::const_iterator iter = val.begin();
iter != val.end();
iter++) {
- if (*iter >= 0x30 && *iter < 0x7F) {
- out.append(1, asciiTable[*iter - 0x30]);
+ if (*iter >= 0x20 && *iter < 0x7F) {
+ out.append(1, asciiTable[*iter - 0x20]);
} else {
out.append(1, LOSSCHAR);
}
Modified: logging/log4cxx/trunk/src/test/cpp/helpers/transcodertestcase.cpp
URL: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/test/cpp/helpers/transcodertestcase.cpp?rev=807031&r1=807030&r2=807031&view=diff
==============================================================================
--- logging/log4cxx/trunk/src/test/cpp/helpers/transcodertestcase.cpp (original)
+++ logging/log4cxx/trunk/src/test/cpp/helpers/transcodertestcase.cpp Sun Aug 23 23:24:37
2009
@@ -60,7 +60,9 @@
LOGUNIT_TEST(uencode3);
LOGUNIT_TEST(uencode5);
#endif
-
+ LOGUNIT_TEST(encodeCharsetName1);
+ LOGUNIT_TEST(encodeCharsetName2);
+ LOGUNIT_TEST(encodeCharsetName3);
LOGUNIT_TEST_SUITE_END();
@@ -304,6 +306,34 @@
#endif
+ void encodeCharsetName1() {
+ const logchar utf8[] = { 0x75, 0x74, 0x66, 0x2D, 0x38, 0x00 };
+ std::string encoded(Transcoder::encodeCharsetName(LogString(utf8)));
+ LOGUNIT_ASSERT_EQUAL(std::string("utf-8"), encoded);
+ }
+
+ void encodeCharsetName2() {
+ logchar lascii[0x60];
+ char ascii[0x60];
+ for(int i = 0; i < 0x5F; i++) {
+ lascii[i] = i + 0x20;
+ ascii[i] = i + 0x20;
+ }
+ lascii[0x5F] = 0;
+ ascii[0x5F] = 0;
+ std::string encoded(Transcoder::encodeCharsetName(LogString(ascii)));
+ LOGUNIT_ASSERT_EQUAL(std::string(" !\"#$%&'()*+,-./"), encoded.substr(0,
0x10));
+ if (0x40 == 'A') {
+ LOGUNIT_ASSERT_EQUAL(std::string(ascii), encoded);
+ }
+ }
+
+ void encodeCharsetName3() {
+ logchar unsupported[] = { 0x1F, 0x7F, 0x80, 0x81, 0x00 };
+ std::string encoded(Transcoder::encodeCharsetName(LogString(unsupported)));
+ LOGUNIT_ASSERT_EQUAL(std::string("????"), encoded);
+ }
+
};
LOGUNIT_TEST_SUITE_REGISTRATION(TranscoderTestCase);
Use apr, apr-util, expat, log4cxx libraries compiled with -fPIC flag. It works in my case. On Thu, Jul 30, 2009 at 9:06 AM, Curt Arnold <carnold@apache.org> wrote: > > On Jul 16, 2009, at 7:43 AM, abgimeno wrote: > > >> Hi >> >> I have the same problem and I could not solve. I have installed the >> version >> apache-log4cxx-0.10.0. apr-1.3.6 and apr-util-1.3.8. in a Red Hat 5 x64 >> >> I tried with the patch 596934 and does not work. >> >> >> When the program ends gives an exception >> >> terminate called after throwing an instance of >> 'log4cxx::helpers::MutexException' >> what(): Mutex exception: stat = 22 >> ./tester.sh: line 71: 17226 Aborted ./tester >> >> > I'l try to fire up a copy of CentOS 5 x64 this weekend. > > Did it occur during the unit tests or one of the sample applications, or in > some other context? >
On Jul 16, 2009, at 7:43 AM, abgimeno wrote: > > Hi > > I have the same problem and I could not solve. I have installed the > version > apache-log4cxx-0.10.0. apr-1.3.6 and apr-util-1.3.8. in a Red Hat 5 > x64 > > I tried with the patch 596934 and does not work. > > > When the program ends gives an exception > > terminate called after throwing an instance of > 'log4cxx::helpers::MutexException' > what(): Mutex exception: stat = 22 > ./tester.sh: line 71: 17226 Aborted ./tester > I'l try to fire up a copy of CentOS 5 x64 this weekend. Did it occur during the unit tests or one of the sample applications, or in some other context?
Hi
I have the same problem and I could not solve. I have installed the version
apache-log4cxx-0.10.0. apr-1.3.6 and apr-util-1.3.8. in a Red Hat 5 x64
I tried with the patch 596934 and does not work.
When the program ends gives an exception
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 22
./tester.sh: line 71: 17226 Aborted ./tester
Rhosyn wrote:
>
> The attach patch fixes a thread safety issue we found with ObjectPtrBase
> when we ported our application to a 64 bit platform.
>
> It will only work if you are using a version of apr with
> apr_atomic_xchgptr()
>
>
> Cheers
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> ---
> /home/rhosyn/SVN/oakx41/main/thirdparty/log4cxx/_build/app.host/app/apache-log4cxx-0.10.0/src/main/cpp/objectptr.cpp
> 2008-03-31 23:34:09.000000000 +0100
> +++
> /home/rhosyn/SVN/oakx41/main/thirdparty/log4cxx/_build/app.app/app/apache-log4cxx-0.10.0/src/main/cpp/objectptr.cpp
> 2009-01-07 15:39:03.000000000 +0000
> @@ -36,12 +36,7 @@
> void* ObjectPtrBase::exchange(void** destination, void* newValue) {
> #if _WIN32 && (!defined(_MSC_VER) || _MSC_VER >= 1300)
> return InterlockedExchangePointer(destination, newValue);
> -#elif APR_SIZEOF_VOIDP == 4
> - return (void*) apr_atomic_xchg32((volatile apr_uint32_t*) destination,
> - (apr_uint32_t) newValue);
> #else
> - void* oldValue = *destination;
> - *destination = newValue;
> - return oldValue;
> + apr_atomic_xchgptr((volatile void**)destination, newValue);
> #endif
> }
>
>
--
View this message in context: http://www.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p24515613.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Hi
I have the same problem and I could not solve. I have installed the version
apache-log4cxx-0.10.0. apr-1.3.6 and apr-util-1.3.8. in a Red Hat 5 x64
I tried with the patch 596934 and does not work.
When the program ends gives an exception
terminate called after throwing an instance of
'log4cxx::helpers::MutexException'
what(): Mutex exception: stat = 22
./tester.sh: line 71: 17226 Aborted ./tester
Rhosyn wrote:
>
> The attach patch fixes a thread safety issue we found with ObjectPtrBase
> when we ported our application to a 64 bit platform.
>
> It will only work if you are using a version of apr with
> apr_atomic_xchgptr()
>
>
> Cheers
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
> ---
> /home/rhosyn/SVN/oakx41/main/thirdparty/log4cxx/_build/app.host/app/apache-log4cxx-0.10.0/src/main/cpp/objectptr.cpp
> 2008-03-31 23:34:09.000000000 +0100
> +++
> /home/rhosyn/SVN/oakx41/main/thirdparty/log4cxx/_build/app.app/app/apache-log4cxx-0.10.0/src/main/cpp/objectptr.cpp
> 2009-01-07 15:39:03.000000000 +0000
> @@ -36,12 +36,7 @@
> void* ObjectPtrBase::exchange(void** destination, void* newValue) {
> #if _WIN32 && (!defined(_MSC_VER) || _MSC_VER >= 1300)
> return InterlockedExchangePointer(destination, newValue);
> -#elif APR_SIZEOF_VOIDP == 4
> - return (void*) apr_atomic_xchg32((volatile apr_uint32_t*) destination,
> - (apr_uint32_t) newValue);
> #else
> - void* oldValue = *destination;
> - *destination = newValue;
> - return oldValue;
> + apr_atomic_xchgptr((volatile void**)destination, newValue);
> #endif
> }
>
>
--
View this message in context: http://www.nabble.com/log4cxx-0.10.0%3A-Fix-for-64-bit-only-thread-safety-bug-in-ObjectPtrBase-tp21504865p24512413.html
Sent from the Log4cxx - Dev mailing list archive at Nabble.com.
Hi, I am getting segmentation fault from log4cxx when running on 64 bit platform (linux). Though its working fine on 32 bit machine. Can you please help me out? gdb back trace output:--- #0 apr_pool_create_ex (newpool=0x8b1940, parent=0x8b8418, abort_fn=0, allocator=0x8b4300) at memory/unix/apr_pools.c:249 #1 0x00000000005a5e20 in Pool (this=0x8b1940) at pool.cpp:34 #2 0x00000000005bda4d in log4cxx::helpers::CharsetEncoder::createDefaultEncoder () at charsetencoder.cpp:370 #3 0x00000000005be0f3 in log4cxx::helpers::CharsetEncoder::getDefaultEncoder () at charsetencoder.cpp:436 #4 0x00000000005b5772 in log4cxx::helpers::Transcoder::encode (src=@0x7fbffff300, dst=@0x7fbffff2c0) at transcoder.cpp:288 #5 0x00000000005aee83 in log4cxx::helpers::SystemErrWriter::write (str=@0x7fbffff300) at systemerrwriter.cpp:67 #6 0x00000000005b661f in log4cxx::WriterAppender::writeFooter (this=0x8c2330, p=@0x8c2398) at writerappender.cpp:227 #7 0x00000000005b6842 in log4cxx::WriterAppender::closeWriter (this=0x8c2330) at writerappender.cpp:157 #8 0x00000000005b69ff in log4cxx::WriterAppender::close (this=0x8c2330) at writerappender.cpp:143 #9 0x000000000058815d in ~ConsoleAppender (this=0x0) at consoleappender.cpp:57 #10 0x00000000004e9601 in ~ObjectPtrT (this=0x8c22e0) at ../../../src/main/include/log4cxx/helpers/objectptr.h:100 #11 0x00000000005b9aad in ~AppenderAttachableImpl (this=0x8c2940) #12 0x0000000000590905 in ~Logger (this=0x8bc4c0, __vtt_parm=<value optimized out>) at ../../../src/main/include/log4cxx/helpers/objectptr.h:100 #13 0x00000000005fa9ca in ~RootLogger (this=0x0) at ../../../src/main/include/log4cxx/spi/rootlogger.h:37 #14 0x00000000004e75ba in ~CdxMsgrC (this=0x88fc00) at /usr/releng/external/log4cxx-0.10.0/include/log4cxx/helpers/objectptr.h:100 #15 0x00000000004e805a in __static_initialization_and_destruction_0 (__initialize_p=<value optimized out>, __priority=21) #16 0x00000000004d724d in __do_global_dtors_aux () #17 0x0000007fbffff618 in ?? () #18 0x00000000006ba1bd in _fini () #19 0x0000007fbffff618 in ?? () #20 0x0000002a95c6ec85 in exit () from /lib64/tls/libc.so.6 #21 0x00000000004dac28 in main (argc=<value optimized out>, argv=0x7fbffff618)
>
> hi,
> log4cxx::NDC::cloneStack() and inherit() functions are missing from
> 0.10.0.
> Is there any work around for these functions in the 0.10.0.
> I want to inherit the NDC stack of the parent thread to the child
> thread.
>
Thanks
Deepak
hi, log4cxx::NDC::cloneStack() and inherit() functions are missing from 0.10.0. Is there any work around for these functions in the 0.10.0. I want to inherit the NDC stack of the parent thread to the child thread. Thanks Deepak
Hi, Is there any way through which I can inherit the NDC stack to the child thread? I have a parent thread running and create a child thread, I want the NDC stack of the parentthread should also be applied to the child thread. Please let me know if we have anyway to do that? Thnaks Deepak
Hi,
I am using NDC (*nested diagnostic contexts*) for appending the text from
a specific thread.
Using floowing code:
-------------------------
//In side the run method of that thread
log4cxx::NDC::push("Thread specific Info");
printing some log4cxx messages.......
//Just before exiting the thread
log4cxx::NDC::pop();
-------------------------------
But the issue is I am not able to get the "Thread specific Info" message in
any of the messages I am printing in that thread.
I am using log4cxx 0.10.0 version.
Please let me know if you have any idea.
Thanks
Deepak
On Tue, Jun 9, 2009 at 8:48 AM, Curt Arnold<carnold@apache.org> wrote: > > On Jun 8, 2009, at 11:05 AM, George Morgan wrote: > >> I'm planning to use libstrophe for the XMPP interface and was >> wondering what I need to ask the author of that library in order to >> not preclude inclusion of my code in log4cxx? > > The standard distribution is licensed under the GPL. See > http://www.apache.org/licenses/GPL-compatibility.html for why Apache > projects can't link to GPL licensed projects. Apache, BSD or MIT style > licenses are not a problem. I'm guessing that LGPL would not be compatible either then... I'm going to talk to the copyright owner for libstrophe and see if there is a chance that he would change the license. -- George Morgan
On Jun 8, 2009, at 11:05 AM, George Morgan wrote: > I've started porting the IMAppender from log4j-sandbox to log4cxx. I > am hoping to produce code which is suitable for inclusion in the > log4cxx distribution. > > Is there is a list of guidelines for inclusion somewhere? > > I've looked over the code and was wondering if I should base my new > appender on the AppenderSkeleton or the SocketAppenderSkeleton? > > I'm planning to use libstrophe for the XMPP interface and was > wondering what I need to ask the author of that library in order to > not preclude inclusion of my code in log4cxx? The standard distribution is licensed under the GPL. See http://www.apache.org/licenses/GPL-compatibility.html for why Apache projects can't link to GPL licensed projects. Apache, BSD or MIT style licenses are not a problem. > > > Since I am only planning to develop support for the XMPP/Jabber > protocol would it make more sense to call the appender, "XMPPAppender" > or "JabberAppender" instead of IMAppender? > > Thanks. > > -- > George Morgan Can't write more at the moment.
I've started porting the IMAppender from log4j-sandbox to log4cxx. I am hoping to produce code which is suitable for inclusion in the log4cxx distribution. Is there is a list of guidelines for inclusion somewhere? I've looked over the code and was wondering if I should base my new appender on the AppenderSkeleton or the SocketAppenderSkeleton? I'm planning to use libstrophe for the XMPP interface and was wondering what I need to ask the author of that library in order to not preclude inclusion of my code in log4cxx? Since I am only planning to develop support for the XMPP/Jabber protocol would it make more sense to call the appender, "XMPPAppender" or "JabberAppender" instead of IMAppender? Thanks. -- George Morgan
Hi, Do we have any config option in log4cxx to redirect log4cxx output to stderr on linux? Thanks Deepak
I am using following pattern layout, Using [%-5t] to print the
thread name which prints in hexadecimal.
Is there any way to print thread ID in decimal.
log4cxx::PatternLayout("%c-%p (%d{dd MMM yyyy HH:mm}) [%-5t] %m%n")
Thanks
Deepak
hi Curt,
Thanks for the mail.
In My code, I wanted to check for incorrect configuration file.
Is there any way to know that if
log4cxx::PropertyConfigurator::configure(log4cxx::File(file));
does not succeed. (apart form getting error message to the cosole). Doe it
provide anything which we can handle programatically if function returns
error?
-------------------Code-----------------
void InitLog(const char *file)
{
log4cxx::PropertyConfigurator::configure(log4cxx::File(file));
}
----------
On Mon, May 25, 2009 at 6:50 PM, Curt Arnold <carnold@apache.org> wrote:
> log4cxx follows the pattern set by log4j which is to silently swallow any
> configuration errors. Add a log4j.debug=true to your property file and you
> may get some diagnostic output to the console. Otherwise, post your
> configuration file here and we can help.
>
>
>
> On May 24, 2009, at 3:14 PM, deepak singh wrote:
>
> Hi,
>> I am using property file to configure the log4cxx. I am not able to check
>> the correctness of the input property file.
>> I tried the try, catch but PropertyConfigurator::configure function is
>> not throwing any exception.
>> I passed the dummy property file and in this case configure file printing
>> following messages on the console :
>>
>> log4cxx: No appender could be found for logger (root).
>> log4cxx: Please initialize the log4cxx system properly.
>>
>>
>> Please let me know how to catch this error?
>> -------------------Code-----------------
>> void InitLog(const char *file)
>> {
>> log4cxx::PropertyConfigurator::configure(log4cxx::File(file));
>> }
>>
>
>
log4cxx follows the pattern set by log4j which is to silently swallow
any configuration errors. Add a log4j.debug=true to your property
file and you may get some diagnostic output to the console.
Otherwise, post your configuration file here and we can help.
On May 24, 2009, at 3:14 PM, deepak singh wrote:
> Hi,
> I am using property file to configure the log4cxx. I am not able to
> check the correctness of the input property file.
> I tried the try, catch but PropertyConfigurator::configure function
> is not throwing any exception.
> I passed the dummy property file and in this case configure file
> printing following messages on the console :
>
> log4cxx: No appender could be found for logger (root).
> log4cxx: Please initialize the log4cxx system properly.
>
>
> Please let me know how to catch this error?
> -------------------Code-----------------
> void InitLog(const char *file)
> {
> log4cxx::PropertyConfigurator::configure(log4cxx::File(file));
> }
Hi,
I am using property file to configure the log4cxx. I am not able to check
the correctness of the input property file.
I tried the try, catch but PropertyConfigurator::configure function is not
throwing any exception.
I passed the dummy property file and in this case configure file printing
following messages on the console :
log4cxx: No appender could be found for logger (root).
log4cxx: Please initialize the log4cxx system properly.
Please let me know how to catch this error?
-------------------Code-----------------
void InitLog(const char *file)
{
log4cxx::PropertyConfigurator::configure(log4cxx::File(file));
}
Hi I've been running into some issues when compiling log4cxx. Mostly standard library functions that aren't declared before they are used. I attached a patch that fixes the problems I found. CXX=/nettools/sunstudio/sunstudio11/SUNWspro/bin/CC CC=/nettools/sunstudio/sunstudio11/SUNWspro/bin/cc ./configure --with-apr=/src/work/mw/log4cxx-sunstudio11/apr-1.3.3 --with-apr-util=/src/work/mw/log4cxx-sunstudio/apr-util-1.3.4 --prefix=/src/work/mw/log4cxx-sunstudio11/log4cxx-build CXXFLAGS="-library=stlport4" bash$ CC -V CC: Sun C++ 5.8 Patch 121018-11 2007/05/02 bash$ uname -a SunOS pegasus 5.10 Generic_118855-33 i86pc i386 i86pc Best regards, Cosmin
Author: carnold
Date: Mon Apr 27 03:53:50 2009
New Revision: 768863
URL: http://svn.apache.org/viewvc?rev=768863&view=rev
Log:
LOGCXX-332: fails to build with gcc 4.4
Modified:
logging/log4cxx/trunk/src/examples/cpp/console.cpp
Modified: logging/log4cxx/trunk/src/examples/cpp/console.cpp
URL: http://svn.apache.org/viewvc/logging/log4cxx/trunk/src/examples/cpp/console.cpp?rev=768863&r1=768862&r2=768863&view=diff
==============================================================================
--- logging/log4cxx/trunk/src/examples/cpp/console.cpp (original)
+++ logging/log4cxx/trunk/src/examples/cpp/console.cpp Mon Apr 27 03:53:50 2009
@@ -23,6 +23,8 @@
#include <iostream>
#include <locale.h>
#include <cstring>
+#include <cstdio>
+#include <stdint.h>
using namespace log4cxx;
using namespace log4cxx::helpers;
Thanks Curt, problem solved.
On Thu, Apr 9, 2009 at 8:33 PM, Curt Arnold <carnold@apache.org> wrote:
>
> On Apr 9, 2009, at 4:17 AM, Lijuan Zhu wrote:
>
> More debugging showed where the error was:
>>
>> In the misc.c around line 161
>>
>> FARPROC apr_load_dll_func(apr_dlltoken_e fnLib, char* fnName, int ordinal)
>> {
>> if (!lateDllHandle[fnLib]) {
>> lateDllHandle[fnLib] = LoadLibrary(lateDllName[fnLib]);
>> if (!lateDllHandle[fnLib])
>> return NULL;
>> }
>> if (ordinal)
>> return GetProcAddress(lateDllHandle[fnLib], (char *) ordinal);
>> else
>> return GetProcAddress(lateDllHandle[fnLib], fnName);
>> }
>>
>> The LoadLibrary("kernel32") returned NULL, which caused the problem.
>>
>> The error code is 126, can not find the module kernel32 ? why it can not
>> find the kernel32.dll, it is in the c:\windows\system32 ...
>>
>> Anyone can help me out?
>>
>> Thanks,
>> Lijuan
>>
>>
> Looks like an APR issue, try searching the APR mailing list and bugzilla (
> http://apr.apache.org) before asking on user@apr.apache.org. If you ask
> there, specify the precise version of Windows you are using, what value of
> the arguments to apr_stat and the expected and actual results. More likely
> to get a quicker response there.
>
On Apr 9, 2009, at 4:17 AM, Lijuan Zhu wrote:
> More debugging showed where the error was:
>
> In the misc.c around line 161
>
> FARPROC apr_load_dll_func(apr_dlltoken_e fnLib, char* fnName, int
> ordinal)
> {
> if (!lateDllHandle[fnLib]) {
> lateDllHandle[fnLib] = LoadLibrary(lateDllName[fnLib]);
> if (!lateDllHandle[fnLib])
> return NULL;
> }
> if (ordinal)
> return GetProcAddress(lateDllHandle[fnLib], (char *) ordinal);
> else
> return GetProcAddress(lateDllHandle[fnLib], fnName);
> }
>
> The LoadLibrary("kernel32") returned NULL, which caused the problem.
>
> The error code is 126, can not find the module kernel32 ? why it can
> not find the kernel32.dll, it is in the c:\windows\system32 ...
>
> Anyone can help me out?
>
> Thanks,
> Lijuan
>
Looks like an APR issue, try searching the APR mailing list and
bugzilla (http://apr.apache.org) before asking on
user@apr.apache.org. If you ask there, specify the precise version of
Windows you are using, what value of the arguments to apr_stat and the
expected and actual results. More likely to get a quicker response
there.
More debugging showed where the error was:
In the misc.c around line 161
FARPROC apr_load_dll_func(apr_dlltoken_e fnLib, char* fnName, int ordinal)
{
if (!lateDllHandle[fnLib]) {
lateDllHandle[fnLib] = LoadLibrary(lateDllName[fnLib]);
if (!lateDllHandle[fnLib])
return NULL;
}
if (ordinal)
return GetProcAddress(lateDllHandle[fnLib], (char *) ordinal);
else
return GetProcAddress(lateDllHandle[fnLib], fnName);
}
The LoadLibrary("kernel32") returned NULL, which caused the problem.
The error code is 126, can not find the module kernel32 ? why it can not
find the kernel32.dll, it is in the c:\windows\system32 ...
Anyone can help me out?
Thanks,
Lijuan
On Thu, Apr 9, 2009 at 12:23 PM, Lijuan Zhu <zhu.lijuan@gmail.com> wrote:
>
>
> On Thu, Apr 9, 2009 at 12:03 PM, Curt Arnold <carnold@apache.org> wrote:
>
>> Try using forward slashes in the file name. If that doesn't work, start
>> with a file no directory specification. log4cxx uses APR which provides a
>> consistent API above the filesystem including trying to provide a consistent
>> file specification format (as does Java) and takes forward slashes on all
>> platforms.
>>
>> If you are using the property configuration, backslashes are escape
>> sequences and will get mangled (double backslashes should work fine).
>> Wouldn't think it would affect you if you were using XML configuration.
>>
>> The file open is in src/fileoutputstream.cpp around line 54.
>
>
> I tried to debug into it, but did not hit the breakpoint into
> src/fileoutputstream.cpp
>
> This is my call stack: (failed in GetFileAttributesExW, because the file
> does not exist ...)
>
> > pslog.dll!apr_winapi_GetFileAttributesExW(const unsigned short *
> lpFileName=0x001286e8, _GET_FILEEX_INFO_LEVELS
> fInfoLevelId=GetFileExInfoStandard, void * lpFileInformation=0x00128494)
> Line 204 + 0x3a bytes C
> pslog.dll!apr_stat(apr_finfo_t * finfo=0x0012c760, const char *
> fname=0x0188c500, int wanted=256, apr_pool_t * pool=0x0188c040) Line 496 +
> 0x15 bytes C
> pslog.dll!log4cxx::File::length(log4cxx::helpers::Pool & pool={...})
> Line 171 + 0x24 bytes C++
>
> pslog.dll!log4cxx::rolling::RollingFileAppenderSkeleton::activateOptions(log4cxx::helpers::Pool
> & p={...}) Line 106 + 0xc bytes C++
>
> pslog.dll!log4cxx::RollingFileAppender::activateOptions(log4cxx::helpers::Pool
> & pool={...}) Line 153 C++
>
> pslog.dll!log4cxx::config::PropertySetter::activate(log4cxx::helpers::Pool
> & p={...}) Line 102 + 0x37 bytes C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::parseAppender(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * appenderElement=0x01891a40, apr_xml_doc *
> doc=0x01891100,
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 264 C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * element=0x01891a40, apr_xml_doc *
> doc=0x01891100, const
> std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > & appenderName="MyRollingAppenderSize",
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 131 + 0x23 bytes C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * element=0x01891918, apr_xml_doc *
> doc=0x01891100, const
> std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > & appenderName="MyRollingAppenderSize",
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 135 + 0x2a bytes C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByReference(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * appenderRef=0x0188c438, apr_xml_doc *
> doc=0x01891100,
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 159 + 0x29 bytes C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * loggerElement=0x0188c330,
> log4cxx::helpers::ObjectPtrT<log4cxx::Logger> logger={...}, bool
> isRoot=true, apr_xml_doc * doc=0x01891100,
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 463 + 0x20 bytes C++
>
> pslog.dll!log4cxx::xml::DOMConfigurator::parseRoot(log4cxx::helpers::Pool &
> p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * rootElement=0x0188c330, apr_xml_doc *
> doc=0x01891100,
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 436 C++
> pslog.dll!log4cxx::xml::DOMConfigurator::parse(log4cxx::helpers::Pool
> & p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
> utf8Decoder={...}, apr_xml_elem * element=0x01891918, apr_xml_doc *
> doc=0x01891100,
> std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> >
> >,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
> appenders=[0]()) Line 938 C++
> pslog.dll!log4cxx::xml::DOMConfigurator::doConfigure(const
> log4cxx::File & filename={...},
> log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository> &
> repository1={...}) Line 742 C++
> pslog.dll!log4cxx::xml::DOMConfigurator::configure(const
> std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> > & filename="d:\SVN\projectwise\ncpe\bin\tf.log.xml") Line 756 + 0x64
> bytes C++
>
>
>>
>>
>>
>> On Apr 8, 2009, at 10:30 PM, Lijuan Zhu wrote:
>>
>> I am new to log4cxx, and just got it set up into my application. I
>>> configured a xml file for the logging, but the log file like c:\temp.log
>>> could not be created by the log4cxx. I am sure my app has the privelegesto
>>> create file.
>>> I would like to debug the source code, would someone please point me to
>>> the source code?
>>>
>>> Thanks,
>>> Lijuan
>>>
>>
>>
>
On Thu, Apr 9, 2009 at 12:03 PM, Curt Arnold <carnold@apache.org> wrote:
> Try using forward slashes in the file name. If that doesn't work, start
> with a file no directory specification. log4cxx uses APR which provides a
> consistent API above the filesystem including trying to provide a consistent
> file specification format (as does Java) and takes forward slashes on all
> platforms.
>
> If you are using the property configuration, backslashes are escape
> sequences and will get mangled (double backslashes should work fine).
> Wouldn't think it would affect you if you were using XML configuration.
>
> The file open is in src/fileoutputstream.cpp around line 54.
I tried to debug into it, but did not hit the breakpoint into
src/fileoutputstream.cpp
This is my call stack: (failed in GetFileAttributesExW, because the file
does not exist ...)
> pslog.dll!apr_winapi_GetFileAttributesExW(const unsigned short *
lpFileName=0x001286e8, _GET_FILEEX_INFO_LEVELS
fInfoLevelId=GetFileExInfoStandard, void * lpFileInformation=0x00128494)
Line 204 + 0x3a bytes C
pslog.dll!apr_stat(apr_finfo_t * finfo=0x0012c760, const char *
fname=0x0188c500, int wanted=256, apr_pool_t * pool=0x0188c040) Line 496 +
0x15 bytes C
pslog.dll!log4cxx::File::length(log4cxx::helpers::Pool & pool={...})
Line 171 + 0x24 bytes C++
pslog.dll!log4cxx::rolling::RollingFileAppenderSkeleton::activateOptions(log4cxx::helpers::Pool
& p={...}) Line 106 + 0xc bytes C++
pslog.dll!log4cxx::RollingFileAppender::activateOptions(log4cxx::helpers::Pool
& pool={...}) Line 153 C++
pslog.dll!log4cxx::config::PropertySetter::activate(log4cxx::helpers::Pool
& p={...}) Line 102 + 0x37 bytes C++
pslog.dll!log4cxx::xml::DOMConfigurator::parseAppender(log4cxx::helpers::Pool
& p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * appenderElement=0x01891a40, apr_xml_doc *
doc=0x01891100,
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 264 C++
pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool
& p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * element=0x01891a40, apr_xml_doc *
doc=0x01891100, const
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> & appenderName="MyRollingAppenderSize",
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 131 + 0x23 bytes C++
pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByName(log4cxx::helpers::Pool
& p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * element=0x01891918, apr_xml_doc *
doc=0x01891100, const
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> & appenderName="MyRollingAppenderSize",
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 135 + 0x2a bytes C++
pslog.dll!log4cxx::xml::DOMConfigurator::findAppenderByReference(log4cxx::helpers::Pool
& p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * appenderRef=0x0188c438, apr_xml_doc *
doc=0x01891100,
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 159 + 0x29 bytes C++
pslog.dll!log4cxx::xml::DOMConfigurator::parseChildrenOfLoggerElement(log4cxx::helpers::Pool
& p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * loggerElement=0x0188c330,
log4cxx::helpers::ObjectPtrT<log4cxx::Logger> logger={...}, bool
isRoot=true, apr_xml_doc * doc=0x01891100,
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 463 + 0x20 bytes C++
pslog.dll!log4cxx::xml::DOMConfigurator::parseRoot(log4cxx::helpers::Pool &
p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * rootElement=0x0188c330, apr_xml_doc *
doc=0x01891100,
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 436 C++
pslog.dll!log4cxx::xml::DOMConfigurator::parse(log4cxx::helpers::Pool &
p={...}, log4cxx::helpers::ObjectPtrT<log4cxx::helpers::CharsetDecoder> &
utf8Decoder={...}, apr_xml_elem * element=0x01891918, apr_xml_doc *
doc=0x01891100,
std::map<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>,log4cxx::helpers::ObjectPtrT<log4cxx::Appender>,std::less<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
>
>,std::allocator<std::pair<std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> const ,log4cxx::helpers::ObjectPtrT<log4cxx::Appender> > > > &
appenders=[0]()) Line 938 C++
pslog.dll!log4cxx::xml::DOMConfigurator::doConfigure(const
log4cxx::File & filename={...},
log4cxx::helpers::ObjectPtrT<log4cxx::spi::LoggerRepository> &
repository1={...}) Line 742 C++
pslog.dll!log4cxx::xml::DOMConfigurator::configure(const
std::basic_string<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>
> & filename="d:\SVN\projectwise\ncpe\bin\tf.log.xml") Line 756 + 0x64
bytes C++
>
>
>
> On Apr 8, 2009, at 10:30 PM, Lijuan Zhu wrote:
>
> I am new to log4cxx, and just got it set up into my application. I
>> configured a xml file for the logging, but the log file like c:\temp.log
>> could not be created by the log4cxx. I am sure my app has the privelegesto
>> create file.
>> I would like to debug the source code, would someone please point me to
>> the source code?
>>
>> Thanks,
>> Lijuan
>>
>
>
sorry, I was wrong. If I don't specify any directory, the log file was created, and log worked fine. But I retried the forward slashes, did not work ... On Thu, Apr 9, 2009 at 12:07 PM, Lijuan Zhu <zhu.lijuan@gmail.com> wrote: > Curt, thanks again! > > I am using the xml configuration file, and tried forward slashes, no > directory before I asking the question, still no luck... > > On Thu, Apr 9, 2009 at 12:03 PM, Curt Arnold <carnold@apache.org> wrote: > >> Try using forward slashes in the file name. If that doesn't work, start >> with a file no directory specification. log4cxx uses APR which provides a >> consistent API above the filesystem including trying to provide a consistent >> file specification format (as does Java) and takes forward slashes on all >> platforms. >> >> If you are using the property configuration, backslashes are escape >> sequences and will get mangled (double backslashes should work fine). >> Wouldn't think it would affect you if you were using XML configuration. >> >> The file open is in src/fileoutputstream.cpp around line 54. >> >> >> >> On Apr 8, 2009, at 10:30 PM, Lijuan Zhu wrote: >> >> I am new to log4cxx, and just got it set up into my application. I >>> configured a xml file for the logging, but the log file like c:\temp.log >>> could not be created by the log4cxx. I am sure my app has the privelegesto >>> create file. >>> I would like to debug the source code, would someone please point me to >>> the source code? >>> >>> Thanks, >>> Lijuan >>> >> >> >
Curt, thanks again! I am using the xml configuration file, and tried forward slashes, no directory before I asking the question, still no luck... On Thu, Apr 9, 2009 at 12:03 PM, Curt Arnold <carnold@apache.org> wrote: > Try using forward slashes in the file name. If that doesn't work, start > with a file no directory specification. log4cxx uses APR which provides a > consistent API above the filesystem including trying to provide a consistent > file specification format (as does Java) and takes forward slashes on all > platforms. > > If you are using the property configuration, backslashes are escape > sequences and will get mangled (double backslashes should work fine). > Wouldn't think it would affect you if you were using XML configuration. > > The file open is in src/fileoutputstream.cpp around line 54. > > > > On Apr 8, 2009, at 10:30 PM, Lijuan Zhu wrote: > > I am new to log4cxx, and just got it set up into my application. I >> configured a xml file for the logging, but the log file like c:\temp.log >> could not be created by the log4cxx. I am sure my app has the privelegesto >> create file. >> I would like to debug the source code, would someone please point me to >> the source code? >> >> Thanks, >> Lijuan >> > >
Try using forward slashes in the file name. If that doesn't work, start with a file no directory specification. log4cxx uses APR which provides a consistent API above the filesystem including trying to provide a consistent file specification format (as does Java) and takes forward slashes on all platforms. If you are using the property configuration, backslashes are escape sequences and will get mangled (double backslashes should work fine). Wouldn't think it would affect you if you were using XML configuration. The file open is in src/fileoutputstream.cpp around line 54. On Apr 8, 2009, at 10:30 PM, Lijuan Zhu wrote: > I am new to log4cxx, and just got it set up into my application. I > configured a xml file for the logging, but the log file like c: > \temp.log could not be created by the log4cxx. I am sure my app has > the privelegesto create file. > I would like to debug the source code, would someone please point me > to the source code? > > Thanks, > Lijuan
I am new to log4cxx, and just got it set up into my application. I configured a xml file for the logging, but the log file like c:\temp.log could not be created by the log4cxx. I am sure my app has the privelegesto create file. I would like to debug the source code, would someone please point me to the source code? Thanks, Lijuan
Hi All Facing some trouble because of Log4cxx when the Filesystem is full ... Seems like whenever the Filesystem is full log4cxx throws an IOException ... I am using RollingFileAppender under unix enviornment ... What I essentially want is for the logger to stop logging as soon as the filesystem is full ... although I achieved this by putting simple try/catch blocks around log4cxx wrappers in my code ... but this drastically degraded my applications performance ... and I am unable to figure out the reason ... however application regains normality when some space is freed up from filesystem .... Tried the same stuff using log4j and turns out ...that it doesn't throw any exception to the application when out of disk space(why cant log4cxx do that ???) .... Can anyone please suggest an alternate approach or workaround ... as i don't want to handle this exception at my application level ... Any suggestions will be valuable and greatly appreciated
Resending because didn't get an answer. Seem like folks were on holidays... ------------------------------------------------------------------------------------------------ Hello, guys! Seems like log4cxx 0.10.0 doesn't build with libc6 2.8 and g++ 4.3.2 under Ubuntu 8.10. Functions memmove(), memcpy(), and strcmp() don't resolve. The problems are in files: ./src/main/cpp/inputstreamreader.cpp ./src/main/cpp/socketoutputstream.cpp ./src/examples/cpp/console.cpp Adding #include <string.h> to the above files fixes the problem. I made a patch but maybe you have some abstraction over standard libc6 headers. So tell me what to do. Should I submit this stuff somewhere? Viktor Kazakov P.S. This latest version of libc6 brought pain to many builds I guess...
Curt Arnold wrote:
>
> On Jan 16, 2009, at 9:34 AM, Rhosyn wrote:
>
>> Dear all,
>>
>>
>> The crashes
>> ===========
>>
>> We would like to share with you some patches to log4cxx we have found
>> useful in our environment.
>>
>> Our product (a Linux platform server product, compiled with g++ 4.3.x)
>> started suffering from crashes during (what should have been) graceful
>> process exit ("exit(0);")- after we replaced our old logging framework
>> with a log4cxx backend.
>>
>> Commonly we would see segmentation faults in:
>>
>> * log4cxx::helpers::ObjectPtrBase()
>> * log4cxx::LogManager::getLoggerLS()
>>
>>
>>
>> The cause
>> =========
>>
>> We eventually traced this issue to the pervasive pattern of (mis)usage
>> of singletons in the log4cxx code.
>>
>> The log4cxx library uses the "Meyers" singleton pattern, first
>> popularised in Scott Meyers "Effective C++" (Item 47 in the 2nd edition
>> of that book):
>>
>> Thing & getThingSingleton()
>> {
>> static Thing t;
>> return t;
>> }
>>
>>
>> For many years, the above pattern was considered "best practice" for
>> using Singletons in C++ - and was generally safe for most popular
>> compiler implementations and most applications.
>>
>> Unfortunately, this recommendation is not actually guaranteed to be
>> thread-safe for construction or destruction - something which is alluded
>> to on Scott Meyers' own "Errata List for Effective C++, Second Edition"
>> as described here: http://www.aristeia.com/BookErrata/ec++2e-errata.html
>>
>>
>> The nub of the problem is that when a process calls "exit(0);" or
>> similar, one thread will start running, in order, any user-registered
>> "atexit" functions.
>>
>> Along with these, the compiler will execute the (conceptually similar)
>> compiler-registered functions which invoke the destructors of any static
>> file or function scope objects (also in order - the reverse order to
>> static object construction).
>>
>> Unfortunately, other threads may still be in the process of running -and
>> logging, perhaps using the static objects - during or after the
>> execution of their destructors - thus opening the door to a bunch of
>> potential SEGFAULTs.
>>
>>
>> Solutions
>> =========
>>
>> Andrei Alexandrescu goes into a lot of detail about this C++ design
>> problem in chapter 6 of "Modern C++ design" and proposes two elegant
>> solutions - a "Phoenix Singleton" or SingletonHolder class.
>>
>> The patches attached are somewhat less elegant than either of
>> Alexandrescus suggestions (we were pressed for time and needed a quick
>> fix in order to ship on time).
>>
>> However, the patches supplied are simple, pragmatic - and did appear to
>> hold up during our testing (testing which was readily producing the
>> crashes described earlier, before we patched).
>>
>> In summary, the patches change Singleton functions to work thus:
>>
>> Thing & getThingSingleton()
>> {
>> static Thing * t = new t;
>> return *t;
>> }
>>
>> Of course, the downside of this flavour of fix is that:
>>
>> * the static objects - now allocated on the heap with new() - never get
>> their destructors run. AFAIK, no other resources (other than memory)
>> appear to be leaked (due to this patch). Fortunately, as we are running
>> on a modern OS, we are able to rely on the OS to reclaim the process
>> memory on process exit - thus nullifying this particular issue for our
>> product (but not neccessarily so in other environments).
>>
>> * The patch doesn't address the startup/initialisation race (for that
>> we'd need a multiple-locked singleton initialization pattern everywhere
>> log4cxx creates a singleton) - we're less worried about that at this
>> stage as we have yet to notice any issues.
>>
>> apr
>> ===
>>
>> Finally we couldn't work out how it could ever be safe to deiinitialise
>> APR if there was even the slightest chance that any extant log4cxx
>> objects existed (accessible to any thread). We therefore removed the
>> apr_terminate() call in APRInitializer::~APRInitializer()
>>
>>
>> Future
>> ======
>>
>> I would like to respecfully suggest that there is a discussion in the
>> log4cxx community about the best way of reworking the use of singletons
>> in the log4cxx library (multithreaded-safe construction and
>> destruction) - and that we look to moving towards a different pattern
>> of usage.
>>
>> I suspect Alexandrescu's "singleton holder" idea might form a part of a
>> possible solution - but it's not the only game in town.
>>
>>
>>
>
> Thanks for the analysis.
>
> There is a bit of tension here since those who are running under
> BoundsChecker, Valgrind, Purify et al will then complain about leaks.
> Probably the best approach is to try to isolate the singleton pattern
> into a preprocessor macro and then allow the user to select what
> singleton pattern they'd like to use.
>
> Please file this as a bug report at http://issues.apache.org/jira
>
Thanks; JIRA issue LOGCXX-322 raised, as requested.
I totally see your point re: BoundsChecker, Valgrind etc. and also re:
isolating the behaviour.
A more sophisticated patch than my first cut is definitely the order of
the day!
Curt Arnold wrote: > > On Jan 16, 2009, at 10:45 AM, Rhosyn wrote: > >> Dear all, >> >> We would like to share with you a patch we use for log4cxx in order to >> prevent an exception being raised when a very long message is logged. >> >> We found our system was sometimes misbehaving due to an exception being >> raised by log4cxx when a very large message was logged - but only when >> the SyslogAppender/SyslogWriter was in use (other appenders "worked" >> perfectly). >> >> We eventually traced the issue to the message(s) in question being too >> large to fit inside a UDP packet (the syslog protocol uses UDP). >> >> We didn't want to massively restructure our program logic to be able to >> recover from rare logging errors e.g. by placing message length checking >> code or exception handling code around every call to every trace >> function which might ever need to log a long message (after all, >> logging, although important & useful, is not the focus of our >> application - and "massive" log messages are a rarity ). >> >> We were particularly certain that this course of action best suited our >> needs, given that the syslogappender wasn't the only appender in use and >> the other appenders were capturing the entire message safely. >> >> Therefore we felt it pragmatic to instead simply truncate messages that >> are too long to be sent safely in a UDP packet just prior to sending >> them. >> >> The patch attached does just that - hopefully someone else will find it >> useful! >> >> I would suggest it might be worth rolling a similar patch into any >> future log4cxx release - although I also accept that that is a >> philosophical point - and others might actually prefer the current >> behaviour (although, as discussed previously, it is not behaviour that >> we can easily/safely live with in our current project) >> >> Cheers, >> >> > > log4j also had similar issues which I assume log4cxx inherited. See > https://issues.apache.org/bugzilla/show_bug.cgi?id=42087 > > It would likely be good to align log4cxx with the current log4j > implementation. Again, please file a JIRA issue with this and even > better if you submit a patch with it. > Thanks; JIRA issue LOGCXX-324 raised, as requested. I haven't yet submitted a patch as my current attempt is a way off being aligned with the log4j implementation.
Curt Arnold wrote: > > On Jan 16, 2009, at 11:53 AM, Rhosyn wrote: > >> We found we needed this tiny patch in our environment to compile >> objectptr with various warnings enabled and warnings-as-errors when >> using g++ 4.1.x >> >> Please find the patch attached - it simply explicitly initialises the >> base class in the initializer list. >> >> Cheers, >> > > Thanks. Again a JIRA issue would be the preferred. > Thanks for the feedback. JIRA issue LOGCXX-323 raised, as requested.
On Jan 16, 2009, at 11:53 AM, Rhosyn wrote: > We found we needed this tiny patch in our environment to compile > objectptr with various warnings enabled and warnings-as-errors when > using g++ 4.1.x > > Please find the patch attached - it simply explicitly initialises the > base class in the initializer list. > > Cheers, > Thanks. Again a JIRA issue would be the preferred.
On Jan 16, 2009, at 11:47 AM, Rhosyn wrote: > The attach patch fixes a thread safety issue we found with > ObjectPtrBase > when we ported our application to a 64 bit platform. > > It will only work if you are using a version of apr with > apr_atomic_xchgptr() > > > Cheers > apr_atomic_xchgptr was added at our request just for this reason, but last I checked it hadn't made it into a released version of APR, but likely that has changed. Would be good to change the configure script to detect whether APR has apr_atomic_xchgptr (unless you have a better way to detect it) and modify the code to use it if available.
On Jan 16, 2009, at 10:45 AM, Rhosyn wrote: > Dear all, > > We would like to share with you a patch we use for log4cxx in order to > prevent an exception being raised when a very long message is logged. > > We found our system was sometimes misbehaving due to an exception > being > raised by log4cxx when a very large message was logged - but only > when > the SyslogAppender/SyslogWriter was in use (other appenders "worked" > perfectly). > > We eventually traced the issue to the message(s) in question being too > large to fit inside a UDP packet (the syslog protocol uses UDP). > > We didn't want to massively restructure our program logic to be able > to > recover from rare logging errors e.g. by placing message length > checking > code or exception handling code around every call to every trace > function which might ever need to log a long message (after all, > logging, although important & useful, is not the focus of our > application - and "massive" log messages are a rarity ). > > We were particularly certain that this course of action best suited > our > needs, given that the syslogappender wasn't the only appender in use > and > the other appenders were capturing the entire message safely. > > Therefore we felt it pragmatic to instead simply truncate messages > that > are too long to be sent safely in a UDP packet just prior to sending > them. > > The patch attached does just that - hopefully someone else will find > it > useful! > > I would suggest it might be worth rolling a similar patch into any > future log4cxx release - although I also accept that that is a > philosophical point - and others might actually prefer the current > behaviour (although, as discussed previously, it is not behaviour that > we can easily/safely live with in our current project) > > Cheers, > > log4j also had similar issues which I assume log4cxx inherited. See https://issues.apache.org/bugzilla/show_bug.cgi?id=42087 It would likely be good to align log4cxx with the current log4j implementation. Again, please file a JIRA issue with this and even better if you submit a patch with it.
On Jan 16, 2009, at 9:34 AM, Rhosyn wrote:
> Dear all,
>
>
> The crashes
> ===========
>
> We would like to share with you some patches to log4cxx we have found
> useful in our environment.
>
> Our product (a Linux platform server product, compiled with g++
> 4.3.x)
> started suffering from crashes during (what should have been) graceful
> process exit ("exit(0);")- after we replaced our old logging framework
> with a log4cxx backend.
>
> Commonly we would see segmentation faults in:
>
> * log4cxx::helpers::ObjectPtrBase()
> * log4cxx::LogManager::getLoggerLS()
>
>
>
> The cause
> =========
>
> We eventually traced this issue to the pervasive pattern of (mis)usage
> of singletons in the log4cxx code.
>
> The log4cxx library uses the "Meyers" singleton pattern, first
> popularised in Scott Meyers "Effective C++" (Item 47 in the 2nd
> edition
> of that book):
>
> Thing & getThingSingleton()
> {
> static Thing t;
> return t;
> }
>
>
> For many years, the above pattern was considered "best practice" for
> using Singletons in C++ - and was generally safe for most popular
> compiler implementations and most applications.
>
> Unfortunately, this recommendation is not actually guaranteed to be
> thread-safe for construction or destruction - something which is
> alluded
> to on Scott Meyers' own "Errata List for Effective C++, Second
> Edition"
> as described here: http://www.aristeia.com/BookErrata/ec++2e-errata.html
>
>
> The nub of the problem is that when a process calls "exit(0);" or
> similar, one thread will start running, in order, any user-registered
> "atexit" functions.
>
> Along with these, the compiler will execute the (conceptually similar)
> compiler-registered functions which invoke the destructors of any
> static
> file or function scope objects (also in order - the reverse order to
> static object construction).
>
> Unfortunately, other threads may still be in the process of running -
> and
> logging, perhaps using the static objects - during or after the
> execution of their destructors - thus opening the door to a bunch of
> potential SEGFAULTs.
>
>
> Solutions
> =========
>
> Andrei Alexandrescu goes into a lot of detail about this C++ design
> problem in chapter 6 of "Modern C++ design" and proposes two elegant
> solutions - a "Phoenix Singleton" or SingletonHolder class.
>
> The patches attached are somewhat less elegant than either of
> Alexandrescus suggestions (we were pressed for time and needed a quick
> fix in order to ship on time).
>
> However, the patches supplied are simple, pragmatic - and did appear
> to
> hold up during our testing (testing which was readily producing the
> crashes described earlier, before we patched).
>
> In summary, the patches change Singleton functions to work thus:
>
> Thing & getThingSingleton()
> {
> static Thing * t = new t;
> return *t;
> }
>
> Of course, the downside of this flavour of fix is that:
>
> * the static objects - now allocated on the heap with new() - never
> get
> their destructors run. AFAIK, no other resources (other than memory)
> appear to be leaked (due to this patch). Fortunately, as we are
> running
> on a modern OS, we are able to rely on the OS to reclaim the process
> memory on process exit - thus nullifying this particular issue for our
> product (but not neccessarily so in other environments).
>
> * The patch doesn't address the startup/initialisation race (for that
> we'd need a multiple-locked singleton initialization pattern
> everywhere
> log4cxx creates a singleton) - we're less worried about that at this
> stage as we have yet to notice any issues.
>
> apr
> ===
>
> Finally we couldn't work out how it could ever be safe to
> deiinitialise
> APR if there was even the slightest chance that any extant log4cxx
> objects existed (accessible to any thread). We therefore removed the
> apr_terminate() call in APRInitializer::~APRInitializer()
>
>
> Future
> ======
>
> I would like to respecfully suggest that there is a discussion in the
> log4cxx community about the best way of reworking the use of
> singletons
> in the log4cxx library (multithreaded-safe construction and
> destruction) - and that we look to moving towards a different pattern
> of usage.
>
> I suspect Alexandrescu's "singleton holder" idea might form a part
> of a
> possible solution - but it's not the only game in town.
>
>
>
Thanks for the analysis.
There is a bit of tension here since those who are running under
BoundsChecker, Valgrind, Purify et al will then complain about leaks.
Probably the best approach is to try to isolate the singleton pattern
into a preprocessor macro and then allow the user to select what
singleton pattern they'd like to use.
Please file this as a bug report at http://issues.apache.org/jira
The attached patch fixes an infinite loop in log4cxx if a module hierarchy name of "." was used in certain circumstances/API calls which ended up in calling Hierarchy::updateParents Hope this helps someone! Cheers, ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
We found we needed this tiny patch in our environment to compile objectptr with various warnings enabled and warnings-as-errors when using g++ 4.1.x Please find the patch attached - it simply explicitly initialises the base class in the initializer list. Cheers, ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
The attach patch fixes a thread safety issue we found with ObjectPtrBase when we ported our application to a 64 bit platform. It will only work if you are using a version of apr with apr_atomic_xchgptr() Cheers ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________