subject:"LOG4CXX crashes"

Re: log4cxx crashes on application exit

2017-05-23 Thread Thorsten Schöning

Guten Tag Bonneau, Guy,
am Montag, 22. Mai 2017 um 21:02 schrieben Sie:

> Hierarchy::~Hierarchy(){
> 
> delete loggers;
> delete provisionNodes;}

A workaround is applied to current trunk for this problem:

https://issues.apache.org/jira/browse/LOGCXX-430

Additionally have a look at the related/linked issues. Especially
yours, but even the current version of log4cxx has problems with
thread-safetiness because of LOGCXX-322. Some workarounds are applied
at trunk to make it somewhat working, though.

https://issues.apache.org/jira/browse/LOGCXX-322

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: log4cxx crashes on application exit

2017-05-22 Thread Robert Middleton

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
<guy.bonn...@grassvalley.com> 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 <dave.birds...@esgyn.com>
> 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 <log4cxx-user@logging.apache.org>
> 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<std::string, std::pair const, log4cxx::helpers::ObjectPtrT >,
> std::_Select1st<std::pair log4cxx::helpers::ObjectPtrT > >, std::less,
> std::allocator<std::pair log4cxx::helpers::ObjectPtrT > >
>>::_M_erase(std::_Rb_tree_node<std::pair 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 on application exit

2017-05-22 Thread Bonneau, Guy

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 <dave.birds...@esgyn.com>
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 <log4cxx-user@logging.apache.org>
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<mailto: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<std::string, std::pair >, 
std::_Select1st<std::pair > >, std::less, 
std::allocator<std::pair > > 
>::_M_erase(std::_Rb_tree_node<std::pair > >*) () 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 on application exit

2017-05-22 Thread Dave Birdsall

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 <log4cxx-user@logging.apache.org>
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<mailto: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<std::string, std::pair >, 
std::_Select1st<std::pair > >, std::less, 
std::allocator<std::pair > > 
>::_M_erase(std::_Rb_tree_node<std::pair > >*) () 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 on application exit

2017-05-22 Thread Dave Birdsall

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<std::string, std::pair >, 
std::_Select1st<std::pair > >, std::less, 
std::allocator<std::pair > > 
>::_M_erase(std::_Rb_tree_node<std::pair > >*) () 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

log4cxx crashes on application exit

2017-05-22 Thread Bonneau, Guy

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, 
std::_Select1st >, std::less, 
std::allocator > 
>::_M_erase(std::_Rb_tree_node >*) () 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

2017-04-04 Thread Thorsten Schöning

Guten Tag Rai, Ashish,
am Dienstag, 4. April 2017 um 03:45 schrieben Sie:

> Log4cxx version : Version: 0.10.0 (installed in 32-bit because our 
> application is in 32-bit)

Is this a pre-build version shipped by your distribution? If so,
please try again with your own build of a current trunk, which has a
lot of bug fixes applied since 0.10.0 has been released.

Additionally, this way you are able to use the test suite which might
reveal something regarding your issue. If your distribution provides
the test suite for your current version already as well, I suggest
start using that first.

You can find build instructions for both versions online:

https://logging.apache.org/log4cxx/latest_stable/index.html
https://logging.apache.org/log4cxx/next_stable/index.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

LOG4CXX crashes

2017-04-03 Thread Rai, Ashish


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::_Rep::_S_create(unsigned int, unsigned int, 
std::allocator const&) () from /usr/lib/libstdc++.so.6

#9  0x03c78029 in std::basic_string::_Rep::_M_clone(std::allocator const&, unsigned 
int) ()

   from /usr/lib/libstdc++.so.6

#10 0x03c78578 in std::basic_string::reserve(unsigned int) () from /usr/lib/libstdc++.so.6

#11 0x03c78a5b in std::basic_string::append(std::basic_string const&) () from /usr/lib/libstdc++.so.6

#12 0x07653c0f in 
log4cxx::pattern::LiteralPatternConverter::format(log4cxx::helpers::ObjectPtrT
 const&, std::basic_string&, log4cxx::helpers::Pool&) const () from /log4cxx/lib/liblog4cxx.so.10

#13 0x076778e5 in log4cxx::PatternLayout::format(std::basic_string&, 
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 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/app/lib/libapp.so

#29 0x0064b8bb in ThreadFilter::runThreadPool(void*) () from 
apps/app/lib/libapp.so

#30 0x00967a49 in start_thread () from /lib/libpthread.so.0

#31 0x01471aee in clone () from /lib/libc.so.6

This is code snippet for function :

CORBA::Long AppServer::getSomething (CORBA::Environment& env) throw 
(CORBA::SystemException)
{
  LOG4CXX_DEBUG (logger,"AppServer::getSomething called!" );
  something++;
  return something;
}

Let me know if you need more detail.

Thanks & Regards,
Ashish Rai
M: 404-988-8983

Re: log4cxx crashes on application exit

Re: log4cxx crashes on application exit

Re: log4cxx crashes on application exit

RE: log4cxx crashes on application exit

RE: log4cxx crashes on application exit

log4cxx crashes on application exit

Re: LOG4CXX crashes

LOG4CXX crashes

8 matches

Site Navigation

Mail list logo

Footer information