You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4cxx-user@logging.apache.org by Mihai Rusu <di...@roedu.net> on 2005/07/14 15:57:03 UTC
x86_64 problems
Hi
We are using log4cxx in a small project here. Our initial development
platform was x86 but now we want slowly to also add x86_64 support for
our project. We have found 2 strange things happening with log4cxx 0.9.7
on x86_64 different than on x86:
- it seems to putput an empty log message when destroying a LoggerPtr
object
- it seems to crash (gdb shows a crash in log4cxx library)
Obviously, this all can happen just because of our code bugs. But Im
trying to debug and see why it happens. I thought I should first update
to latest log4cxx CVS and try to reproduce the problem with that.
Unfortunetely I don't seem to be able to compile CVS on x86_64. After
installing apr and apr-util 0.9.6 when I try to compile
log4cxx-0.9.8_cvs14072005_030502.tar.gz I get this error:
asyncappender.cpp: In member function `virtual void
log4cxx::AsyncAppender::close()':
asyncappender.cpp:111: error: `apr_atomic_xchg32' undeclared (first use
this function)
asyncappender.cpp:111: error: (Each undeclared identifier is reported
only once for each function it appears in.)
Anyway, do you know of any log4cxx 0.9.7 x86_64 bugs ? Do you know of
some happy users of this library on this platform ?
Thanks!
--
Mihai RUSU Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
Re: x86_64 problems
Posted by Mihai Rusu <di...@roedu.net>.
On Thu, Jul 14, 2005 at 12:29:55PM -0500, Curt Arnold wrote:
>
> The CVS HEAD requires 1.x versions of apr and apr-util, not 0.9.x. I
> had considered attempting to support both APR-0.9.x and APR-1.x, but
> it added much too much complication.
>
> I occasionally check x86_64 builds. I haven't checked it recently,
> but I don't know any problems.
Ok... Now I dont get either of the bugs but I still get a crash which
seems traced to log4cxx codes. The crash happens after main() returns so
it must be called from some destructor of some global variables. The
trace is:
#0 0x00002aaaac872d5f in memcpy () from /lib/tls/libc.so.6
No symbol table info available.
#1 0x00002aaaac533baf in std::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >::_Rep::_M_clone ()
from //usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/libstdc++.so.6
No symbol table info available.
#2 0x00002aaaac533c5a in std::basic_string<wchar_t,
std::char_traits<wchar_t>, std::allocator<wchar_t> >::basic_string ()
from //usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/libstdc++.so.6
No symbol table info available.
#3 0x00002aaaab391244 in log4cxx::NDC::get () at ndc.cpp:99
stack = (
std::stack<log4cxx::NDC::DiagnosticContext,std::deque<log4cxx::NDC::DiagnosticContext,
std::allocator<log4cxx::NDC::DiagnosticContext> > > &) @0x0: Cannot
access memory at address 0x0
Hmmm, seems to be something related to a NULL address, what is that
stack and what should it do ? Or any other hints to further debug this
problem...
Thanks!
--
Mihai RUSU Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
apr 1.1.1 no IPv6 problems (was Re: x86_64 problems)
Posted by Mihai Rusu <di...@roedu.net>.
On Fri, Jul 15, 2005 at 02:23:29PM +0300, Mihai Rusu wrote:
> Ok, but it seems to fail in "simplesocketserver", "performance", "tests"
> (and any program linking to log4cxx) because of:
> /usr/lib/libapr-1.so: undefined reference to `sock_is_ipv6'
> /usr/lib/libapr-1.so: undefined reference to `find_if_index'
>
> Any idea ?
Hmm, this might not be the best place for this message but it seems that
apr 1.1.1 has some nasty bugs (showed up when linking against libapr
when had apr compiled without IPv6 but it seems to affect users
compiling with IPv6 too). My quick hack/fix is:
--- apr-1.1.1/network_io/unix/multicast.c 2005-03-16 00:41:02.000000000 +0200
+++ apr-1.1.1.dizzy/network_io/unix/multicast.c 2005-07-15 16:25:19.000000000 +0300
@@ -56,7 +56,6 @@
}
}
-#if APR_HAVE_IPV6
static unsigned int find_if_index(const apr_sockaddr_t *iface)
{
unsigned int index = 0;
@@ -76,6 +75,7 @@
}
for (ifp = ifs; ifp; ifp = ifp->ifa_next) {
+#if APR_HAVE_IPV6
if (ifp->ifa_addr != NULL && ifp->ifa_addr->sa_family == AF_INET6) {
if (memcmp(&iface->sa.sin6.sin6_addr,
&ifp->ifa_addr->sa_data[0],
@@ -84,6 +84,7 @@
break;
}
}
+#endif
}
freeifaddrs(ifs);
@@ -91,6 +92,7 @@
return index;
}
+#if APR_HAVE_IPV6
static void fill_mip_v6(struct ipv6_mreq *mip, const apr_sockaddr_t *mcast,
const apr_sockaddr_t *iface)
{
@@ -145,10 +147,12 @@
if (source != NULL) {
#if MCAST_JOIN_SOURCE_GROUP
- if (sock_is_ipv6(sock))
+ if (sock_is_ipv4(sock))
ip_proto = IPPROTO_IP;
+#if APR_HAVE_IPV6
else if (sock_is_ipv6(sock))
ip_proto = IPPROTO_IPV6;
+#endif
else
return APR_ENOTIMPL;
The sock_is_ipv6 -> sock_is_ipv4 change points to a bug that seems to
affect people compiling with IPv6 too.
--
Mihai RUSU Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
Re: x86_64 problems
Posted by Mihai Rusu <di...@roedu.net>.
Thanks for the reply!
On Fri, Jul 15, 2005 at 12:48:37PM +0200, Andreas Fester wrote:
> Hi,
>
> [...]
> >Hmm, installed apr 1.1.1, apr-util 1.1.2, got a new snapshot of log4cxx
> >CVS and this is what happens at compile time:
>
> you need to pass --with-logchar=wchar_t to the configure script.
> The default for logchar is already changed to utf8 in my dist-tarball
> package, but the simpledateformat does not yet compile with this
> default.
Ok, but it seems to fail in "simplesocketserver", "performance", "tests"
(and any program linking to log4cxx) because of:
/usr/lib/libapr-1.so: undefined reference to `sock_is_ipv6'
/usr/lib/libapr-1.so: undefined reference to `find_if_index'
Any idea ?
PS: sorry to be so much trouble...
--
Mihai RUSU Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
Re: x86_64 problems
Posted by Andreas Fester <An...@gmx.de>.
Hi,
[...]
> Hmm, installed apr 1.1.1, apr-util 1.1.2, got a new snapshot of log4cxx
> CVS and this is what happens at compile time:
you need to pass --with-logchar=wchar_t to the configure script.
The default for logchar is already changed to utf8 in my dist-tarball
package, but the simpledateformat does not yet compile with this
default.
Best Regards,
Andreas
[...]
> simpledateformat.cpp: In constructor
> `AbbreviatedMonthNameToken::AbbreviatedMonthNameToken(int, const
> std::locale*)':
> simpledateformat.cpp:222: error: invalid initialization of reference of
> type 'log4cxx::LogString&' from expression of type
> 'std::basic_string<wchar_t, std::char_traits<wchar_t>,
[...]
Re: x86_64 problems
Posted by Mihai Rusu <di...@roedu.net>.
Hi there
On Thu, Jul 14, 2005 at 12:29:55PM -0500, Curt Arnold wrote:
>
> There are a lot of things that can cause log4cxx 0.9.7 to crash which
> have been fixed in the CVS. Fixing some of these required fairly
> pervasive changes and 0.9.7 can't be easily "patched" to work around
> the problems.
OK.
> The CVS HEAD requires 1.x versions of apr and apr-util, not 0.9.x. I
> had considered attempting to support both APR-0.9.x and APR-1.x, but
> it added much too much complication.
Hmm, installed apr 1.1.1, apr-util 1.1.2, got a new snapshot of log4cxx
CVS and this is what happens at compile time:
g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"log4cxx\"
-DVERSION=\"0.9.8\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DHAVE_LIBBOOST_REGEX=1 -DHAVE_BOOST_REGEX_HPP=1 -DHAVE_UNISTD_H=1
-DHAVE_ALLOCA_H=1 -DHAVE_PTHREAD=1 -DHAVE_THREAD=1 -DHAVE_LIBXML2=1
-DHAVE_XML=1 -I. -I. -I../include -I../include -I/usr/include/libxml2
-DLOG4CXX -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/apr-1
-I/usr/include/apr-1 -D_REENTRANT -g -O2 -MT simpledateformat.lo -MD -MP
-MF .deps/simpledateformat.Tpo -c simpledateformat.cpp -fPIC -DPIC -o
.libs/simpledateformat.o
simpledateformat.cpp: In constructor
`AbbreviatedMonthNameToken::AbbreviatedMonthNameToken(int, const
std::locale*)':
simpledateformat.cpp:222: error: invalid initialization of reference of
type 'log4cxx::LogString&' from expression of type
'std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> >'
simpledateformat.cpp:78: error: in passing argument 1 of `void
log4cxx::helpers::SimpleDateFormatImpl::renderFacet(log4cxx::LogString&,
apr_time_exp_t*, const char*)'
simpledateformat.cpp: In constructor
`FullMonthNameToken::FullMonthNameToken(int, const std::locale*)':
simpledateformat.cpp:266: error: invalid initialization of reference of
type 'log4cxx::LogString&' from expression of type
'std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> >'
simpledateformat.cpp:78: error: in passing argument 1 of `void
log4cxx::helpers::SimpleDateFormatImpl::renderFacet(log4cxx::LogString&,
apr_time_exp_t*, const char*)'
simpledateformat.cpp: In constructor
`AbbreviatedDayNameToken::AbbreviatedDayNameToken(int, const
std::locale*)':
simpledateformat.cpp:385: error: invalid initialization of reference of
type 'log4cxx::LogString&' from expression of type
'std::basic_string<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> >'
simpledateformat.cpp:78: error: in passing argument 1 of `void
log4cxx::helpers::SimpleDateFormatImpl::renderFacet(log4cxx::LogString&,
apr_time_exp_t*, const char*)'
... and it continues like that for 3 screen pages.
--
Mihai RUSU Email: dizzy@roedu.net
GPG : http://dizzy.roedu.net/dizzy-gpg.txt WWW: http://dizzy.roedu.net
"Linux is obsolete" -- AST
Re: x86_64 problems
Posted by Curt Arnold <ca...@apache.org>.
On Jul 14, 2005, at 8:57 AM, Mihai Rusu wrote:
> Hi
>
> We are using log4cxx in a small project here. Our initial development
> platform was x86 but now we want slowly to also add x86_64 support for
> our project. We have found 2 strange things happening with log4cxx
> 0.9.7
> on x86_64 different than on x86:
> - it seems to putput an empty log message when destroying a LoggerPtr
> object
> - it seems to crash (gdb shows a crash in log4cxx library)
>
> Obviously, this all can happen just because of our code bugs. But Im
> trying to debug and see why it happens. I thought I should first
> update
> to latest log4cxx CVS and try to reproduce the problem with that.
> Unfortunetely I don't seem to be able to compile CVS on x86_64. After
> installing apr and apr-util 0.9.6 when I try to compile
> log4cxx-0.9.8_cvs14072005_030502.tar.gz I get this error:
>
> asyncappender.cpp: In member function `virtual void
> log4cxx::AsyncAppender::close()':
> asyncappender.cpp:111: error: `apr_atomic_xchg32' undeclared (first
> use
> this function)
> asyncappender.cpp:111: error: (Each undeclared identifier is reported
> only once for each function it appears in.)
>
> Anyway, do you know of any log4cxx 0.9.7 x86_64 bugs ? Do you know of
> some happy users of this library on this platform ?
There are a lot of things that can cause log4cxx 0.9.7 to crash which
have been fixed in the CVS. Fixing some of these required fairly
pervasive changes and 0.9.7 can't be easily "patched" to work around
the problems.
The CVS HEAD requires 1.x versions of apr and apr-util, not 0.9.x. I
had considered attempting to support both APR-0.9.x and APR-1.x, but
it added much too much complication.
I occasionally check x86_64 builds. I haven't checked it recently,
but I don't know any problems.