Re: Unable to get log4cxx-1.0.0 via vcpkg
Hi,
Here's a sample project that works for me on linux, it should work on
Windows as well(or at least be easy to modify):
https://github.com/rm5248/log4cxx-vcpkg
If you want to build manually, you'll need to build APR, APR-util, and
expat. This issue has some notes on it:
https://issues.apache.org/jira/browse/LOGCXX-510
It is complicated to do manually, so I do not recommend it.
I'll see about updating the version in vcpkg.
-Robert Middleton
On Wed, Apr 12, 2023 at 12:15 AM Alwyn Mok wrote:
>
> Hi Robert,
>
> Thanks for the advice. However, even with the custom port directory for
> vcpkg, we can't seem to compile log4cxx-1.0.0 into a .DLL file
>
> Are you able to advise us on the easiest way to be able to compile
> log4cxx-1.0.0 into a .DLL file on a Windows machine?
>
> A step-by-step guild would be greatly appreciated.
>
> Thanks in advance,
> Alwyn Mok
>
> On Thu, 6 Apr 2023, 12:19 am Robert Middleton, wrote:
>>
>> You will need to make a custom vcpkg ports directory in order to
>> override what is in vcpkg by default. Check the documentation for
>> vcpkg on how to create an overlay ports directory.
>>
>> -Robert Middleton
>>
>> On Wed, Apr 5, 2023 at 4:23 AM Alwyn Mok wrote:
>> >
>> > Hi Sir/Mdm,
>> >
>> >
>> >
>> > Following the instruction in build-vcpkg.md (Building with vcpkg
>> > {#build-vcpkg})
>> >
>> > The default version of log4cxx used is apache-log4cxx-0.13.0 instead of
>> > apache-log4cxx-1.0.0
>> >
>> >
>> >
>> > How may I obtain apache-log4cxx-1.0.0 via vcpkg, in order to build into a
>> > .dll file?
>> >
>> >
>> >
>> > Thanks in advance,
>> >
>> > Alwyn Mok
Re: Unable to get log4cxx-1.0.0 via vcpkg
You will need to make a custom vcpkg ports directory in order to
override what is in vcpkg by default. Check the documentation for
vcpkg on how to create an overlay ports directory.
-Robert Middleton
On Wed, Apr 5, 2023 at 4:23 AM Alwyn Mok wrote:
>
> Hi Sir/Mdm,
>
>
>
> Following the instruction in build-vcpkg.md (Building with vcpkg
> {#build-vcpkg})
>
> The default version of log4cxx used is apache-log4cxx-0.13.0 instead of
> apache-log4cxx-1.0.0
>
>
>
> How may I obtain apache-log4cxx-1.0.0 via vcpkg, in order to build into a
> .dll file?
>
>
>
> Thanks in advance,
>
> Alwyn Mok
Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found
Note that you may also just be able to configure this at runtime. Assuming that you are using a configuration file to configure Log4cxx, you can probably set the ThreadConfigurationType to not name threads, meaning the code is never called. See this documentation for more details: https://logging.apache.org/log4cxx/latest_stable/threading.html#threading-notes -Robert Middleton On Thu, Dec 1, 2022 at 8:20 AM Robert Middleton wrote: > > Hi Michael, > > The best thing for me to recommend is to simply comment out the checks > for SetThreadDescription and GetThreadDescription as you have done. > This is really designed to be an optional feature, such that you can > print out the name of the thread rather than just its ID in hex. At > least under Linux and GDB this also means that the thread name will > show up in the debugger; I assume the same is true on Windows. > > -Robert Middleton > > On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher > wrote: > > > > Hi, > > > > > > > > we have an issue with log4cxx.dll, version 0.13.0; here is what we found > > out so far: > > > > We built log4cxx.dll on a Windows Server 2019 with cmake (from the > > downloaded apache-log4cxx-0.13.0.zip). > > > > In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines > > below activate the SetThreadDescription / GetThreadDescription calls > > (because in the Windows SDK on that machine processthreadapi.h contains > > Set/GetThreadDescription): > > if(WIN32) > > CHECK_SYMBOL_EXISTS(SetThreadDescription > > "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION) > > CHECK_SYMBOL_EXISTS(GetThreadDescription > > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION) > > endif(WIN32) > > And here is the call in threadutility.cpp: > > ... > > #elif LOG4CXX_HAS_SETTHREADDESCRIPTION > >HRESULT hr = SetThreadDescription(static_cast(nativeHandle), > > threadName.c_str()); > > ... > > That means now log4cxx.dll needs an entry point for SetThreadDescription as > > soon as a client program that linked log4cxx.lib is started > > > > I made a small console program (named logConsole) with only one call to > > log4cxx in main() (after the “Hello World!” std::cout output): > > log4cxx::helpers::LogLog::setQuietMode(true); > > On a Windows Server 2019 or on Windows 10, the program starts and I see > > ‘Hello World!’ > > Now the issue: on a Windows Server 2016 (version 1607), the program does > > not start up at all. > > > > In the event viewer’s system log, the following “Application popup” message > > appears: > > Application popup: logConsole.exe - Entry Point Not Found : The procedure > > entry point SetThreadDescription could not be located in the dynamic link > > library C:\Users\xyz\Documents\log4cxx.dll. > > > > > > > > That means any program that uses this log4cxx.dll compiled on Windows 10 > > won’t even start up on Windows Server 2016. > > > > > > > > Here is what Microsoft says in: > > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription > > > > Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: > > SetThreadDescription is only available by Run Time Dynamic Linking in > > KernelBase.dll. > > > > > > > > As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) > > in the source code around the SetThreadDescription and GetThreadDescription > > calls. > > > > > > > > Has anyone an idea what to do to avoid the problem on old machines? > > > > > > > > My first guess is to delete these lines (but then the new calls are never > > made): > > > > if(WIN32) > > CHECK_SYMBOL_EXISTS(SetThreadDescription > > "windows.h;processthreadsapi.h" HAS_SETTHREADDESCRIPTION) > > CHECK_SYMBOL_EXISTS(GetThreadDescription > > "windows.h;processthreadsapi.h" HAS_GETTHREADDESCRIPTION) > > endif(WIN32) > > > > > > > > Thank you in advance for any responses! > > > > > > > > Best Regards, > > > > Michael > > > > > > > >
Re: log4cxx-0.13.0 SetThreadDescription Entry Point Not Found
Hi Michael, The best thing for me to recommend is to simply comment out the checks for SetThreadDescription and GetThreadDescription as you have done. This is really designed to be an optional feature, such that you can print out the name of the thread rather than just its ID in hex. At least under Linux and GDB this also means that the thread name will show up in the debugger; I assume the same is true on Windows. -Robert Middleton On Thu, Dec 1, 2022 at 6:55 AM Michael Schumacher wrote: > > Hi, > > > > we have an issue with log4cxx.dll, version 0.13.0; here is what we found out > so far: > > We built log4cxx.dll on a Windows Server 2019 with cmake (from the downloaded > apache-log4cxx-0.13.0.zip). > > In apache-log4cxx-0.13.0\src\main\include\CMakeLists.txt the four lines below > activate the SetThreadDescription / GetThreadDescription calls (because in > the Windows SDK on that machine processthreadapi.h contains > Set/GetThreadDescription): > if(WIN32) > CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" > HAS_SETTHREADDESCRIPTION) > CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" > HAS_GETTHREADDESCRIPTION) > endif(WIN32) > And here is the call in threadutility.cpp: > ... > #elif LOG4CXX_HAS_SETTHREADDESCRIPTION >HRESULT hr = SetThreadDescription(static_cast(nativeHandle), > threadName.c_str()); > ... > That means now log4cxx.dll needs an entry point for SetThreadDescription as > soon as a client program that linked log4cxx.lib is started > > I made a small console program (named logConsole) with only one call to > log4cxx in main() (after the “Hello World!” std::cout output): > log4cxx::helpers::LogLog::setQuietMode(true); > On a Windows Server 2019 or on Windows 10, the program starts and I see > ‘Hello World!’ > Now the issue: on a Windows Server 2016 (version 1607), the program does not > start up at all. > > In the event viewer’s system log, the following “Application popup” message > appears: > Application popup: logConsole.exe - Entry Point Not Found : The procedure > entry point SetThreadDescription could not be located in the dynamic link > library C:\Users\xyz\Documents\log4cxx.dll. > > > > That means any program that uses this log4cxx.dll compiled on Windows 10 > won’t even start up on Windows Server 2016. > > > > Here is what Microsoft says in: > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription > > Windows Server 2016, Windows 10 LTSB 2016 and Windows 10 version 1607: > SetThreadDescription is only available by Run Time Dynamic Linking in > KernelBase.dll. > > > > As far as I can see there is no Run Time Dynamic Linking (via LoadLibrary) in > the source code around the SetThreadDescription and GetThreadDescription > calls. > > > > Has anyone an idea what to do to avoid the problem on old machines? > > > > My first guess is to delete these lines (but then the new calls are never > made): > > if(WIN32) > CHECK_SYMBOL_EXISTS(SetThreadDescription "windows.h;processthreadsapi.h" > HAS_SETTHREADDESCRIPTION) > CHECK_SYMBOL_EXISTS(GetThreadDescription "windows.h;processthreadsapi.h" > HAS_GETTHREADDESCRIPTION) > endif(WIN32) > > > > Thank you in advance for any responses! > > > > Best Regards, > > Michael > > > >
Re: [log4cxx] Block signals by default?
> (Disclaimer: I only briefly skimmed the PR, so I might got things wrong.) > > Some thoughts: > - I would not impose on applications should handle signals. This could > be a mayor annoyance, especially if applications needs being changed of that > (this refering to the docs about signalfd etc.) > My objective is to not define how applications should handle signals, the documentation is really in terms of "here's a way you can handle signals better." That should be more clear though, so I can update that. > - A question: does log4cxx use signals of its own? > If not, I would use the approach to block all signals before > pthread_create() > and then restore them afterwards. > Log4cxx does not use any signals on its own, so the question is should we do this automatically or not? If you're using signalfd or something similar, there's no need to block signals before a thread starts, as it bypasses the issue at that point. -Robert Middleton
Re: Need help with migrating to 0.12.0
Technical reason:
Since the new version of log4cxx uses std::shared_ptr(instead of the
homegrown smart pointer solution), you need to slightly modify your code to
work. The reason for the shared_ptr is that it's standard, and it fixes
some bugs with regards to reference counting. The original homegrown
solution was implicitly convertible to/from a pointer; shared_ptr is not.
Create a typedef for your appender using the LOG4CXX_PTR_DEF macro:
LOG4CXX_PTR_DEF(ROSConsoleStdioAppender)
Then just create a new shared_ptr with your typedef:
ROSConsoleStdioAppenderPtr(new ROSConsoleStdioAppender());
-Robert Middleton
On Sun, Aug 15, 2021 at 5:37 AM Achmad Fathoni wrote:
> This sample program can be compiled with 0.11.0 but not 0.12.0. The error
> is "Cannot convert ‘ROSConsoleStdioAppender*’ to ‘log4cxx::App
> enderPtr’ {aka ‘std::shared_ptr’}". What change do I
> need to make it works with 0,12.0? Thank you.
>
> #include
> #include
> #include
> #include
> #include
> #include
>
> using namespace log4cxx;
> using namespace log4cxx::helpers;
>
> class ROSConsoleStdioAppender : public log4cxx::AppenderSkeleton
> {
> public:
> ~ROSConsoleStdioAppender()
> {
> }
>
> protected:
> virtual void append(const log4cxx::spi::LoggingEventPtr& event,
> log4cxx::helpers::Pool&)
> {
> }
>
> virtual void close()
> {
> }
>
> virtual bool requiresLayout() const
> {
> return false;
> }
> };
>
> int main(){
> LoggerPtr logger(Logger::getLogger("main"));
> logger->addAppender(new ROSConsoleStdioAppender);
> return 0;
> }
>
Re: Change on the fly at run time
Yes, the easiest way is to reload the config file.
However, you can do this several ways:
1. Instead of using PropertyConfigurator::configure(), use
PropertyConfigurator::configureAndWatch(), which will start a new
thread that will periodically check the config file for changes.
2. Watch the file using some sort of system file notification
API(inotify on Linux; look at QFileSystemWatcher if you use Qt) and
then call PropertyConfigurator::configure().
3. Completely ignore the config file and change settings via code.
This is more complicated, but you can do things like change log levels
and add/remove appenders via the API, which is essentially what
PropertyConfigurator::configure() does in the first place.
-Robert Middleton
On Fri, Nov 13, 2020 at 7:33 PM xpetrl wrote:
>
> Hi List,
>
> As a general question, do I have to reload the config file to change
> properties on the the fly, when my app runs ?
>
> PropertyConfigurator::configure("log4cxx.properties");
>
> something à la monitorInterval exist for c++?
>
> Thanks
>
> xpetrl
>
>
Re: Building the latest log4cxx from source
Sandhya, There has been no release of log4xx 0.11.0. The latest version of 0.10.0 is the latest released version. I use the version of log4cxx that is in the Debian repositories, it is still version 0.10.0 with a few patches applied. Unfortunately I can't provide any information on the multi process logging, that's not a feature that I have ever used. -Robert Middleton On Mon, Nov 26, 2018 at 2:48 PM Sandhya Sundaresan < sandhya.sundare...@esgyn.com> wrote: > Hello again, > Didn’t get any responses to my question below. Any log4cxx developers or > users out there ? A few additional questions : 1. Which version are > you’ll using ? 2. Did you build your own version from the latest > source repository and is it working ok ? 3. Is log4cxx 0.10.0 (from > 2008) really the latest release ? I see references to 0.11.0 in many of the > JIRAs but cannot find it in the Downloads page for log4cxx. > https://logging.apache.org/log4cxx/latest_stable/download.html > > > We are using log4cxx in Apache Trafodion . > > Thanks > > Sandhya > > > > > > *From:* Sandhya Sundaresan > *Sent:* Friday, November 16, 2018 3:40 PM > *To:* d...@logging.apache.org; log4cxx-user@logging.apache.org > *Subject:* Building the latest log4csxx from source > > > > Hi, > > Has anyone built the latest version from the source tree and used it ? > Yesterday while I was looking for version 0.11 (maintenance version) to > download and try , I couldn't find the tar file and today even the broken > link is gone. So I guess I have to build it myself from source. We really > need the support for multiple processes to be able to log to one log file > working. We see incosistencies while using RollingFileAppender today and > the logfiles and backups don't happen until the logging processes stop . > > So we'd like to try with a version that has the fix for > https://issues.apache.org/jira/browse/LOGCXX-412. > > The latest source source seems to have this fix but there is no version > available for download. > > In this JIRA it says we need to set this define LOG4CXX_MULTI_PROCESS > > > > Which Makefile do I set it in so it takes effect ? > > > > Thank you in advance > > Sandhya >
Re: Exception when calling logger->info() method
Two quick thoughts: 1. Have you ensure that the log4cxx dll and your application were compiled with the same version of cl.exe? MS likes to change ABI compatibility between versions and odd bugs like this can come up when calling across the DLL boundary. 2. Is there a reason you aren't using the LOG4CXX_INFO macro? You should be able to simply use that macro to do what you are trying to do here but in an easier way. Ex: LOG4CXX_INFO( logger, "Initializing LCCService. ConfigPath=" << configFolderPath ); I don't know if the second point will do anything, but there could be an issue with your call trying access a temporary variable on the stack. -Robert Middleton On Tue, Mar 13, 2018 at 7:11 PM, Dalecki, Janusz wrote: > Hi, > > I am having problem with the log4xx throwing an exception while calling > logger->info() (it does not happen in Release version). I am using Visual > Studio 2017 with the latest log4cxx 0.10.0. > > I have logger defined like this: > > *log4cxx::**LoggerPtr* *LCCService**::logger(log4cxx::**Logger* > *::getLogger(**"LCCService"**));* > > .. then I try to log a message like this: > > *o.str(**""**);* > > * o **<<* *"Initializing LCCService. ConfigPath="* *<<** > configFolderPath;* > > * logger**->**info(o.str().c_str());* > > That causes an exception: > > … and the stack looks like this: > > Can anyone explained that?. I have to admit I have not been actively using > C++ for some time. > > Regards, > > Janusz > > > > > > -- > > This e-mail contains privileged and confidential information intended for > the use of the addressees named above. If you are not the intended > recipient of this e-mail, you are hereby notified that you must not > disseminate, copy or take any action in respect of any information > contained in it. If you have received this e-mail in error, please notify > the sender immediately by e-mail and immediately destroy this e-mail and > its attachments. >
Re: Re: Next release
My understanding is that the numbers at the end of the library version(e.g. liblog4cxx.so.10.0.0) are for the ABI version, not the software version. See the guide here: https://autotools.io/libtool/version.html They generally follow(at least somewhat) the package version, but I think the reasoning is that if you can have two different versions of the same library installed, and as long as they have a different ABI they will use the appropriate version of the .so file(e.g. a program can link with liblog4cxx.so.10, and if there is a newer version that is not ABI compatible installed as liblog4cxx.so.11, it won't load the ABI-incompatible version). I think there are tools out there that can help determine if the ABI has actually changed or not. -Robert Middleton On Thu, Dec 21, 2017 at 9:07 AM, Bonneau, Guy wrote: > I'm not a Linux expert but I believe the convention under Linux is: > > liblog4cxx.so.MAJOR.MINOR.BUILD > > Having many years elapsed since the last liblog4cxx release I think it would > be less confusing for Linux developers using the log4cxx library to see the > next version of the library increment to 10.1.0. It makes more sense to > increment the MINOR number than the BUILD number. > > Thus personaly I would prefer the next release version to be > liblog4cxx.so.10.1.0 > > Once you made up your own mind about which version numbering you will use to > release the library it is possible to commit an RC4 with the LT_VERSION set > for the next release version in file configure.ac. We would like to get a > snapshot of the GIT repository and thoroughly test the new candidate release. > We have a product that uses the log4cxx library with both Windows and Linux. > > Regards > Guy > > From: Thorsten Schöning > Sent: Thursday, December 21, 2017 2:39 AM > To: Log4CXX User > Subject: [EXTERNAL] Re: Next release > > Guten Tag Bonneau, Guy, > am Mittwoch, 20. Dezember 2017 um 20:39 schrieben Sie: > >> Then what value do you expect to set for the next release since it >> cannot stay the same? Since the API doesn't change do you expect to >> set LT_VERSION to have liblog4cxx.so.11.0.0 or liblog4cxx.so.10.1.0 > > Why not liblog4cxx.so.10.0.1? That's how I understand the docs in > configure.ac and I could try to implement a default increment of > LT_VERSION in the release-scripts available currently. > > LT_VERSION=10:1:0 -> liblog4cxx.so.10.0.1 > LT_VERSION=11:0:0 -> liblog4cxx.so.11.0.0 > > One of those is what I would prefer. While using the last line might > be wrong if no breaking interface was introduced, auto-incrementing > it should always work as well. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.AM-2DSoFT.de_&d=DwIFAw&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=FS_sYZOzl9JFXNzFbJy3VRLa4Kton7YEcXPfx0WjQRA&m=7ruxZWW4EsXu4HsZKx1nSch1Ehj176vqus0rpZZaNwQ&s=FsSHX_5xxvAw9bCLCuwg0mY5Gqfwm9-hqb5fBIIv33Q&e= > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > ** > DISCLAIMER: > Privileged and/or Confidential information may be contained in this message. > If you are not the addressee of this message, you may not copy, use or > deliver this message to anyone. In such event, you should destroy the message > and kindly notify the sender by reply e-mail. It is understood that opinions > or conclusions that do not relate to the official business of the company are > neither given nor endorsed by the company. Thank You.
Re: Sign out request
To unsubscribe from the list, you need to send an email to log4cxx-user-unsubscr...@apache.org See the mailing list page for more info: http://apache.org/foundation/mailinglists.html On Fri, Dec 15, 2017 at 8:55 AM, "Katharina Günther" wrote: > Hallo! > > Can you please cancel my membership and delete my email adress? > > Thank you very much! > > Katharina Günther >
Re: New release for liblog4cxx
Tobi, You might try the dev mailing list, there are some more people there: d...@logging.apache.org -Robert Middleton On Wed, Jul 5, 2017 at 1:59 PM, Tobias Frost wrote: > Hallo, > > The last official release of liblog4cxx was in 2008. Maybe it is time > to cut a new release, as since then lots of improvments have been made > to the library. > > I'm asking for a formal release, as I'd like to update the Debian > packages only with "official releases". And with Debian Stretch out of > the door, it would be the perfect time to prepare an update. > > A question related: Do you think that the SO-name needs to be bumped? > (I didn't find time yet to check with an ABI checker...) > > -- > tobi
Re: log4cxx crashes on application exit
Are these issues the same at all? The stack trace doesn't look the
same, but they may point you in the right direction.
https://issues.apache.org/jira/browse/LOGCXX-216
https://issues.apache.org/jira/browse/LOGCXX-352
-Robert Middleton
On Mon, May 22, 2017 at 3:02 PM, Bonneau, Guy
wrote:
> The issue happens indeed when the Hierarchy destructor attempts to destroy
> the loggers or ProvisionNodes in that code:
>
> Hierarchy::~Hierarchy()
> {
> delete loggers;
> delete provisionNodes;
> }
>
> Since both of these are containers of ObjectPtrT which are shared pointer
> implemented by the library I would expect to nicely exit. Thus I am a little
> bit baffled at this point.
>
>
>
> From: Dave Birdsall
> Sent: Monday, May 22, 2017 2:48 PM
> To: Log4CXX User
>
> Subject: RE: log4cxx crashes on application exit
>
>
> Hi,
>
>
>
> Looking at your stack more carefully, it looks like the ObjectPtrT global
> object is created by the log4cxx code itself. Which makes things harder. It
> looks like it is trying to destroy some underlying objects. The Hierarchy
> destructor seems to be making use of ObjectPtrT and some other things.
> Perhaps there is a way to clean out the Hierarchy object first so that there
> is nothing for it to destroy?
>
>
>
> Dave
>
>
>
> From: Dave Birdsall [mailto:dave.birds...@esgyn.com]
> Sent: Monday, May 22, 2017 11:43 AM
> To: Log4CXX User
> Subject: RE: log4cxx crashes on application exit
>
>
>
> I am not a log4cxx expert, but this looks a bit like the old
> global-object-destructor problem.
>
>
>
> After a C++ program calls exit(), the destructors for all global objects are
> called. The order is non-deterministic, and cannot be influenced by the
> programmer. The order is determined at link edit time. Up until now, you
> have been lucky and the destructors were called in a nice order. But now it
> appears they are not.
>
>
>
> In your case, it looks like an ObjectPtrT object is being destroyed.
>
>
>
> The best way to avoid these kinds of problems is to avoid using global C++
> objects. If you simply must, one workaround is to use a global pointer to a
> C++ object, initialized to null, and wrap all accesses to that pointer with
> code that checks for null, creates the object if so, and stores the pointer.
> Then at exit time, you can write code to explicitly destroy the object (if
> you care), before calling exit(). This workaround is not ideal; it is not
> thread-safe, for example. But you can cause object instances to be created
> in your main before spinning up other threads.
>
>
>
> Dave
>
>
>
> From: Bonneau, Guy [mailto:guy.bonn...@grassvalley.com]
> Sent: Monday, May 22, 2017 11:31 AM
> To: log4cxx-user@logging.apache.org
> Subject: log4cxx crashes on application exit
>
>
>
> We have used log4cxx V0_10_0 since a few years with both Linux and Windows
> without any issues until now. We have a setup to compile and build the
> log4cxx shared library on both Linux and Window. We made a solution (sln)
> that can build with Microsoft VS 2008 up to VS 2013. Our log4cxx is build
> under gentoo for Linux.
>
>
>
> We recently started to have a crash with a testing application under Linux
> Gentoo when a testing application exit and the destruction of the static
> singletons of the log4cxx library proceed. However the same testing
> application doesn't crash under Windows with VS 2013. We would appreciate at
> any hints that could help us fix the crash issue under Linux. The stack of
> the crash is:
>
> #0 0x7f2cde67d805 in ?? () from /lib64/libc.so.6
> #1 0x7f2cde67e878 in ?? () from /lib64/libc.so.6
> #2 0x7f2ce7b829b3 in std::_Rb_tree const, log4cxx::helpers::ObjectPtrT >,
> std::_Select1st log4cxx::helpers::ObjectPtrT > >, std::less,
> std::allocator log4cxx::helpers::ObjectPtrT > >
>>::_M_erase(std::_Rb_tree_node log4cxx::helpers::ObjectPtrT > >*) () from
> /usr/lib64/liblog4cxx.so.10
> #3 0x7f2ce7b80940 in log4cxx::Hierarchy::~Hierarchy() () from
> /usr/lib64/liblog4cxx.so.10
> #4 0x7f2ce7b80b99 in log4cxx::Hierarchy::~Hierarchy() () from
> /usr/lib64/liblog4cxx.so.10
> #5 0x7f2ce7b98c46 in
> log4cxx::spi::DefaultRepositorySelector::~DefaultRepositorySelector() ()
> from /usr/lib64/liblog4cxx.so.10
> #6 0x7f2ce7b989c0 in
> log4cxx::helpers::ObjectPtrT::~ObjectPtrT()
> () from /usr/lib64/liblog4cxx.so.10
> #7 0x7f2cde63beef in __cxa_finalize () from /lib64/libc.so.6
> #8 0x7f2ce7b4ab33 in ?? () from /usr/lib64/liblog4cxx.so.10
>
>
>
> Thanks
>
> Guy Bonneau
>
>
>
>
Re: LOG4CXX crashes
Ashish, A few questions for you: 1. What version of log4cxx are you running? 2. Are you running log4cxx in a multi-threaded application? If yes, the current versions of log4cxx do have problems with multithreaded applications, and that could cause a problem. 3. Does this happen all the time? If it's not happening all of the time it sounds like it could be memory corruption of some kind. -Robert Middleton On Mon, Apr 3, 2017 at 1:14 PM, Rai, Ashish wrote: > > > Hi, > > > > We are getting crashes from log4cxx implementation in our application. Our > application is running on Linux 2.6.32-358.el6.x86_64. It C++ based > application using orbix to interact with Java based GUI. > > > > Please find below stack trace for core dump : > > > > #0 0x0077a430 in __kernel_vsyscall () > > #1 0x013b9b11 in raise () from /lib/libc.so.6 > > #2 0x013bb3ea in abort () from /lib/libc.so.6 > > #3 0x013f99d5 in __libc_message () from /lib/libc.so.6 > > #4 0x013ffe31 in malloc_printerr () from /lib/libc.so.6 > > #5 0x014033ff in _int_malloc () from /lib/libc.so.6 > > #6 0x0140400e in malloc () from /lib/libc.so.6 > > #7 0x03c9a09a in operator new(unsigned int) () from > /usr/lib/libstdc++.so.6 > > #8 0x03c76ed6 in std::basic_string, > std::allocator >::_Rep::_S_create(unsigned int, unsigned int, > std::allocator const&) () from /usr/lib/libstdc++.so.6 > > #9 0x03c78029 in std::basic_string, > std::allocator >::_Rep::_M_clone(std::allocator const&, > unsigned int) () > >from /usr/lib/libstdc++.so.6 > > #10 0x03c78578 in std::basic_string, > std::allocator >::reserve(unsigned int) () from > /usr/lib/libstdc++.so.6 > > #11 0x03c78a5b in std::basic_string, > std::allocator >::append(std::basic_string std::char_traits, std::allocator > const&) () from > /usr/lib/libstdc++.so.6 > > #12 0x07653c0f in log4cxx::pattern::LiteralPatternConverter:: > format(log4cxx::helpers::ObjectPtrT const&, > std::basic_string, std::allocator >&, > log4cxx::helpers::Pool&) const () from /log4cxx/lib/liblog4cxx.so.10 > > #13 0x076778e5 in log4cxx::PatternLayout::format(std::basic_string std::char_traits, std::allocator >&, > log4cxx::helpers::ObjectPtrT const&, > log4cxx::helpers::Pool&) const () from /log4cxx/lib/liblog4cxx.so.10 > > #14 0x076b6636 in log4cxx::WriterAppender::subAppend(log4cxx::helpers:: > ObjectPtrT const&, log4cxx::helpers::Pool&) () > >from /log4cxx/lib/liblog4cxx.so.10 > > #15 0x0768aca4 in log4cxx::rolling::RollingFileAppenderSkeleton:: > subAppend(log4cxx::helpers::ObjectPtrT > const&, log4cxx::helpers::Pool&) () from /log4cxx/lib/liblog4cxx.so.10 > > #16 0x076b5da7 in log4cxx::WriterAppender::append(log4cxx::helpers:: > ObjectPtrT const&, log4cxx::helpers::Pool&) () > >from /log4cxx/lib/liblog4cxx.so.10 > > #17 0x07604aa0 in log4cxx::AppenderSkeleton::doAppend(log4cxx::helpers:: > ObjectPtrT const&, log4cxx::helpers::Pool&) () > >from /log4cxx/lib/liblog4cxx.so.10 > > #18 0x07601065 in log4cxx::helpers::AppenderAttachableImpl:: > appendLoopOnAppenders(log4cxx::helpers::ObjectPtrT > const&, log4cxx::helpers::Pool&) () from /log4cxx/lib/liblog4cxx.so.10 > > #19 0x0765973d in log4cxx::Logger::callAppenders(log4cxx:: > helpers::ObjectPtrT const&, > log4cxx::helpers::Pool&) const () > >from /log4cxx/lib/liblog4cxx.so.10 > > #20 0x076599dd in > log4cxx::Logger::forcedLog(log4cxx::helpers::ObjectPtrT > const&, std::basic_string, > std::allocator > const&, log4cxx::spi::LocationInfo const&) const () > from /log4cxx/lib/liblog4cxx.so.10 > > #21 0x080b07cd in AppServer::getSomething (this=0x8a54cb8, env=...) at > AppServer.cpp:406 > > #22 0x080bae04 in AppModule_AppServerIntfcAppServer::getSomething > (this=0x8a561d8, IT_env=...) at AppServer.h:243 > > #23 0x0829bedb in AppModule::AppServerIntfc_dispatch::dispatch > (this=0x8a41298, IT_r=..., IT_isTarget=1 '\001', IT_pp=0x8a561d8) > > at AppModuleS.cc:229 > > #24 0x019fbdfe in ContextClassS::continueDispatch(RequestS&, > CORBA::Filter*, CORBA::PPTR*) () from /orbix/lib/liborbixmt.3.3. > gcc411.so.1 > > #25 0x019fc109 in ContextClassS::continueThreadDispatch(RequestS&) () > from /orbix/lib/liborbixmt.3.3.gcc411.so.1 > > #26 0x01a06681 in IT_BOAImpl::continueThreadDispatch(CORBA::Request&) () > from /orbix/lib/liborbixmt.3.3.gcc411.so.1 > > #27 0x01a06139 in CORBA::BOA::continueThreadDispatch(CORBA::Request&) () > from /orbix/lib/liborbixmt.3.3.gcc411.so.1 > > #28 0x0064b911 in ThreadFilter::threadPool() () from > /apps/ap
Re: Unix Timestamps
If I'm understanding the code correctly, in your %d{} specifier, you can
define a custom format using apr_strftime(). I'm assuming that this means
you can use the standard strftime() specifiers, but the documentation for
APR is somewhat lacking.
http://man7.org/linux/man-pages/man3/strftime.3.html
-Robert Middleton
On Thu, Dec 1, 2016 at 11:34 AM, Thorsten Schöning
wrote:
> Guten Tag Felix Endres,
> am Donnerstag, 1. Dezember 2016 um 16:37 schrieben Sie:
>
> > is it possible to print a unix timestamp, i.e. seconds since 1970 in the
> > PatternLayout (or any other layout)? Optimally I would like a fractional
> > pattern showing microseconds.
>
> Is your question about the format or timezone handling? A format
> including fractionals is possible and the default already when only
> using "%d", but I'm pretty sure it's not supporting microseconds:
>
> > %d{-MM-dd HH:mm:ss,SSS}
> > 2016-12-01 17:20:43,764
>
> Have a look at the classes datepatternconverter, strftimedateconverter
> and simpledateformat, which is used depending on your configuration
> and might support timezone related stuff. At least there some "Z"
> mentioned in simpledatformat, resulting in a calculation of timezone
> offsets in "RFC822TimeZoneToken".
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...05151- 9468- 55
> Fax...05151- 9468- 88
> Mobil..0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
>
Re: Cannot figure out how to clean correctly
Eventually backwards compatibility has to be broken anyway. If the Level changes, then that would be a good time to switch over to standard(std/boost) smart pointers as well, which may break other code that depends on Object. For the most part I don't think this will have a large impact on library-using code, as at least in my case I only use the LOG4CXX_level macros. Perhaps it would be best to do a release of what currently exists before the backwards compatibility is broken? -Robert Middleton On Thu, Oct 27, 2016 at 5:50 AM, Thorsten Schöning wrote: > Guten Tag Peter Westman, > am Donnerstag, 27. Oktober 2016 um 11:11 schrieben Sie: > > > My suggestion is to have getInfo return a const Level& instead of a > > LevelPtr. > > But that would change the interface and "everyone" would need to change > things. On the other side, "const Level*" would at least be compatible > with the current invocation of LevelPtr on the caller side, but would > fail assignments and such as well. > > So, break back compatibility and if so, with which form? > > I don't use Levels in my codebase, so I'm fine with such a break. ;-) > Additionally I would prefer "const Level&" as well. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
Re: Cannot figure out how to clean correctly
Choosing between the smart pointers should be pretty straight forward: http://stackoverflow.com/questions/7095556/how-to-handle-evolving-c-std-namespace-e-g-stdtr1shared-ptr-vs-std This way people can use either a boost pointer or a C++11 pointer depending on their compiler. I only suggested C++11 since it's several years old at this point and most people should be able to use the new features without problems, but if it's possible to choose between C++11/boost that solves the problem. I think that the memory leak may be a consequence of how the Object class is implemented; references must be incremented/decremented manually, which could explain why the memory doesn't get freed. -Robert Middleton On Thu, Oct 27, 2016 at 3:05 AM, Peter Westman wrote: > I think going for a boost::shared_ptr could be a good idea, most projects > using something as complex as log4cxx should be able to cope with it imho. > Another option would be to use some sort of ifndef rule to determine if > boost or the current implementation is used. > > For levels though, I dont really see why we even have smart pointers? We > could just as easily create the variables statically in the class, and use > them as const references to the original levels. Right now the library is > allocating new dynamic memory on a call basis, which seems pretty wasteful > to me. If we make the storage static (which it was prior to > LOG4CXX-394/r1566655 anyway). In some cases like the Logger class that > stores a changeable level it would have to be a plain pointer, but I > personally dont see a problem with that. > > /Peter > > > On 10/27/2016 08:48 AM, Thorsten Schöning wrote: > >> Guten Tag Robert Middleton, >> am Donnerstag, 27. Oktober 2016 um 01:39 schrieben Sie: >> >> I haven't delved too deeply into the code(I don't have time today), >>> but it looks like all that Object is doing is providing Java-like >>> garbage collection in terms of memory management. >>> >> That was my understanding as well, but than Valgrind shouldn't find >> leaks? >> >> A quick look at >>> the SVN history indicates that the class was first created ~2003, so >>> would it be worth it to discard Object entirely in favor of C++11 >>> std::shared_ptr? >>> >> And what with all those non C++11 people out there? I'm using >> Embarcadero C++Builder for example which doesn't support C++11 very >> well with its legacy compiler and the new CLANG based ones are still >> incompatible with some projects/environments. So at least I'm not that >> interested to merge patches which make my life more difficult... >> >> How about boost::shared_ptr instead? It's no requirement currently, >> but one might argue it's not that different than e.g. apr. In my >> compiler at least boost 1.39 is provided, which would be enough for >> shared_ptr, I'm using those already. 1.39 itself is so old, that it >> might be a reasonable minimum requirement. >> >> Mit freundlichen Grüßen, >> >> Thorsten Schöning >> >> >
Re: Cannot figure out how to clean correctly
I haven't delved too deeply into the code(I don't have time today), but it looks like all that Object is doing is providing Java-like garbage collection in terms of memory management. A quick look at the SVN history indicates that the class was first created ~2003, so would it be worth it to discard Object entirely in favor of C++11 std::shared_ptr? It would be a rather large change but it may also fix many of the multithreading problems given the support for atomic operations on a shared_ptr. The only other thing that it provides is casting/instanceof operations, but the cast is never used and instanceof is used in ~6 places. -Robert Middleton On Wed, Oct 26, 2016 at 4:39 AM, Thorsten Schöning wrote: > Guten Tag Thorsten Schöning, > am Mittwoch, 26. Oktober 2016 um 09:57 schrieben Sie: > > > 458 is not the problem, 394 is why I changed things. So you need to > > find another/better workaround to fix 394 without leaking. > > Another approach would be to first look at why LevelPtr doesn't seem > to delete not needed instances on app end. Creating new instances > itself shouldn't be the problem, especially if it fixes LOGCXX-394, > but I thought LevelPtr is taking care of deleting the created > instances when not needed anymore. > > So maybe just focus on LevelPtr, ObjectPtr and ObjectImpl first. > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
Re: How to find log file name?
Dave, Depending on your specific use case, it may be easier to simply log to a well-known location on the system and point the user to that location. At least one problem with trying to figure out the location programatically is that a single logger can log to multiple sources at once, e.g. multiple files or to a database. Regardless, you can probably use the following sequence(note: I have not tried this myself) 1. Get the logger that you want to get the appender for(that is, you must have a logger that logs to the file you want to get the name of) 2. Use logger.getAppender( std::string name ) or logger.getAppenders() and loop through all of the appenders. 3. Figure out which of the appenders is a FileAppender: https://logging.apache.org/log4cxx/latest_stable/apidocs/classlog4cxx_1_1_file_appender.html (I think you need to use dynamic_cast here, but I'm not positive, I don't do much casting in C++) 4. Call the FileAppender.getFile() method. -Robert Middleton On Mon, Aug 22, 2016 at 6:48 PM, Dave Birdsall wrote: > Hi, > > > > I’m a newbie to log4cxx (and lack familiarity with log4j). > > > > I have what is likely a naïve question. > > > > Suppose I am about to log some information to a log file. I’d like to tell > my user where that log file is (the path and file name) so the user doesn’t > have to hunt for it. Is there a programmatic way to obtain the log file > name? > > > > Thanks, > > > > Dave >
Re: Compiling on Windows
Update on the crash: I don't know what is going on with it, but I have narrowed down how to reproduce it. It turns out that the macros for logging( for example LOG4CXX_ERROR) create a log4cxx::helpers::MessageBuffer oss_; object. This object gets created and the message is logged using it. If the logging level is not valid, the MessageBuffer object is not created, and so the crash does not occur. The strange thing is that the crash happens at the end of the method that the logging statement is in, it does *not* happen when the destructor of the MessageBuffer is called. Windows indicates that this is a BEX error(buffer overflow). One solution that I saw was to make sure the library is compiled with /MD, I checked the output for log4cxx and it is compiled with that, and my program is compiled with -MD. Any ideas on what could be causing it? -Robert Middleton On Wed, Apr 22, 2015 at 10:05 PM, Robert Middleton wrote: > Thorsten, > > Thanks for the information. For future reference, here is what I needed > to get it to build: > > >- Windows compiler(cl). I had the Windows 7 SDK installed, which gave >me the command prompt with cl on PATH and the proper environment >- ant from: http://ant.apache.org/bindownload.cgi >- ant-contrib-1.0b3.jar from: >http://sourceforge.net/projects/ant-contrib/files/ant-contrib/ >- cpptasks-1.0b5.jar from ant-contrib >- xercesImpl.jar from http://xerces.apache.org/mirrors.cgi#binary > > I set my %PATH% to have the ant bin/ directory on it, and put the 3 jar > files on %CLASSPATH%. I then ran ant -Dfind=false -Ddebug=no. This built > the library; I added it to the .pro file with the following, after copying > over the .dll and .lib file to the directory with the .pro: > > win32:CONFIG(release, debug|release): LIBS += -L$$PWD/ -llog4cxx > > > I then copied over the log4cxx include directory and put in logging. > Everything builds cleanly with MSVC, the problem is that as soon as > something gets logged my program crashes - it appears to be happening > within log4cxx, since I can cause it to happen by changing the level of a > log statement. > > -Robert Middleton > > On Wed, Apr 22, 2015 at 3:38 AM, Thorsten Schöning > wrote: > >> Guten Tag Robert Middleton, >> am Mittwoch, 22. April 2015 um 04:31 schrieben Sie: >> >> > I want to use log4cxx on a Windows-based project, and I'm wondering >> > what the easiest way to compile it for Windows is? >> >> I guess that heavily depends on your compiler and toolchain, not sure >> if I read about QT on the list in the past, so you may be the first >> one trying. I would try to start using ANT and see how it's going, my >> experience using Cygwin is not the best if it comes to building >> software, but I didn't ever try with log4cxx. >> >> https://logging.apache.org/log4cxx/building/ant.html >> >> Mit freundlichen Grüßen, >> >> Thorsten Schöning >> >> -- >> Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de >> AM-SoFT IT-Systeme http://www.AM-SoFT.de/ >> >> Telefon...05151- 9468- 55 >> Fax...05151- 9468- 88 >> Mobil..0178-8 9468- 04 >> >> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln >> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow >> >> >
Re: Compiling on Windows
Thorsten, Thanks for the information. For future reference, here is what I needed to get it to build: - Windows compiler(cl). I had the Windows 7 SDK installed, which gave me the command prompt with cl on PATH and the proper environment - ant from: http://ant.apache.org/bindownload.cgi - ant-contrib-1.0b3.jar from: http://sourceforge.net/projects/ant-contrib/files/ant-contrib/ - cpptasks-1.0b5.jar from ant-contrib - xercesImpl.jar from http://xerces.apache.org/mirrors.cgi#binary I set my %PATH% to have the ant bin/ directory on it, and put the 3 jar files on %CLASSPATH%. I then ran ant -Dfind=false -Ddebug=no. This built the library; I added it to the .pro file with the following, after copying over the .dll and .lib file to the directory with the .pro: win32:CONFIG(release, debug|release): LIBS += -L$$PWD/ -llog4cxx I then copied over the log4cxx include directory and put in logging. Everything builds cleanly with MSVC, the problem is that as soon as something gets logged my program crashes - it appears to be happening within log4cxx, since I can cause it to happen by changing the level of a log statement. -Robert Middleton On Wed, Apr 22, 2015 at 3:38 AM, Thorsten Schöning wrote: > Guten Tag Robert Middleton, > am Mittwoch, 22. April 2015 um 04:31 schrieben Sie: > > > I want to use log4cxx on a Windows-based project, and I'm wondering > > what the easiest way to compile it for Windows is? > > I guess that heavily depends on your compiler and toolchain, not sure > if I read about QT on the list in the past, so you may be the first > one trying. I would try to start using ANT and see how it's going, my > experience using Cygwin is not the best if it comes to building > software, but I didn't ever try with log4cxx. > > https://logging.apache.org/log4cxx/building/ant.html > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...05151- 9468- 55 > Fax...05151- 9468- 88 > Mobil..0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > >
Compiling on Windows
Hi, I want to use log4cxx on a Windows-based project, and I'm wondering what the easiest way to compile it for Windows is? I'm not very familiar with compiling on Windows, so would the easiest way just be to use cygwin? Or something else? I'm looking to compile the latest version from the trunk. Also, it's a Qt-based project if that matters at all. -Robert Middleton
