Re: Problems compiling 1.7.0 on redhat el4 64bit

<michael_rytting_at_agilent.com> writes:

> I am attaching a stack trace with symbols enabled.

Thanks!

> I'm using gcc. The default in the makefile.

I think RHEL may have come with two different gcc, a 3 series and a 4
series. What version does 'gcc -v' show?

> I am using the apr that you get from the get-deps.sh
> script. APR_HAS_THREADS is defined.

Just to check, APR_HAS_THREADS is defined to be 1?

It would be good to confirm that at runtime you really are using the
version of libapr you compiled, run ldd on the svn executable.

> If I disable optimizations by doing "make CFLAGS=-O0" the program no
> longer crashes.

That suggests it could be a compiler bug.

> #0 apr_xlate_conv_buffer (convset=0x2d6674752d6e7673,

convset looks to be corrupt, that value is way bigger than the other
pointer values. It looks like ASCII, "-ftu-nvs", but that probably
just means it's random.

> inbuf=0x7fbffffe8a "/cos/home/ryttingm", inbytes_left=0x7fbffff038,
> outbuf=0x54d5a8 "", outbytes_left=0x7fbffff030) at xlate/xlate.c:339
> 339 if (convset->ich != (iconv_t)-1) {
> (gdb)
> Thread 1 (process 14949):
> #0 apr_xlate_conv_buffer (convset=0x2d6674752d6e7673,
> inbuf=0x7fbffffe8a "/cos/home/ryttingm", inbytes_left=0x7fbffff038,
> outbuf=0x54d5a8 "", outbytes_left=0x7fbffff030) at xlate/xlate.c:339
> status = 0
> #1 0x0000002a965a4b95 in convert_to_stringbuf (node=0x2a965bcc30,

node looks to be corrupt as well, that looks like a code value.

Looking at the rest of the stack trace I would say this is the first
call to a utf8 conversion function that would have invoked
get_xlate_handle_node and I suspect it is that function that is going
wrong. At a guess something to do with the use of atomic_swap, which
makes it important to confirm the value of APR_HAS_THREADS.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com