You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2011/08/09 22:55:33 UTC
Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
> ** **
>
> Ok, I’ve tracked down which revision caused the problem. It happened in
> rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
> Ever since this change went in I am seeing subversion crash when I compile
> on 64bit el4.****
>
> ** **
>
> Just for kicks and giggles I updated to the HEAD revision of
> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on
> rev 1104160, cleaned up the conflicts and built it and viola! No more
> crashing when built on 64bit el4.
>
Thanks. Moving the thread to dev@
Can someone look at this and possibly fix it?
If you are not on users@, and to summarize this thread. SVN builds fine on
RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw
the same problem with our builds.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
And of course I forget to actually attach the file.
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com>> wrote:
Ok, I've tracked down which revision caused the problem. It happened in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. Ever since this change went in I am seeing subversion crash when I compile on 64bit el4.
Just for kicks and giggles I updated to the HEAD revision of http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on rev 1104160, cleaned up the conflicts and built it and viola! No more crashing when built on 64bit el4.
Thanks. Moving the thread to dev@
Can someone look at this and possibly fix it?
If you are not on users@, and to summarize this thread. SVN builds fine on RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw the same problem with our builds.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
And of course I forget to actually attach the file.
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com>> wrote:
Ok, I've tracked down which revision caused the problem. It happened in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. Ever since this change went in I am seeing subversion crash when I compile on 64bit el4.
Just for kicks and giggles I updated to the HEAD revision of http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on rev 1104160, cleaned up the conflicts and built it and viola! No more crashing when built on 64bit el4.
Thanks. Moving the thread to dev@
Can someone look at this and possibly fix it?
If you are not on users@, and to summarize this thread. SVN builds fine on RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw the same problem with our builds.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Aug 09, 2011 at 03:02:35PM -0600, michael_rytting@agilent.com wrote:
> P.S. why isn't "make check" structured so that the -j option to make would work. It would be nice to use multiple threads to speed up the run.
You want: make check PARALLEL=1
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 9, 2011 at 4:02 PM, <mi...@agilent.com> wrote:
>
> P.S. why isn’t “make check” structured so that the –j option to make would
> work. It would be nice to use multiple threads to speed up the run.
The testsuite itself is internally parallelized. I don't remember
what the magic options are to enable it, or if it is on by default,
but using -j for make check won't help.
(The reason we parallelize outside of 'make' is that we often run the
tests outside of 'make', and can take advantage of the parallelism in
those scenarios.)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 9, 2011 at 4:02 PM, <mi...@agilent.com> wrote:
>
> P.S. why isn’t “make check” structured so that the –j option to make would
> work. It would be nice to use multiple threads to speed up the run.
The testsuite itself is internally parallelized. I don't remember
what the magic options are to enable it, or if it is on by default,
but using -j for make check won't help.
(The reason we parallelize outside of 'make' is that we often run the
tests outside of 'make', and can take advantage of the parallelism in
those scenarios.)
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I am attaching a patch file which I used to change utf.c in the head revision to get things to play nice with el4 64bit. "make check" does come back clean with this version.
-Mike
P.S. why isn't "make check" structured so that the -j option to make would work. It would be nice to use multiple threads to speed up the run.
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com>> wrote:
Ok, I've tracked down which revision caused the problem. It happened in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. Ever since this change went in I am seeing subversion crash when I compile on 64bit el4.
Just for kicks and giggles I updated to the HEAD revision of http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on rev 1104160, cleaned up the conflicts and built it and viola! No more crashing when built on 64bit el4.
Thanks. Moving the thread to dev@
Can someone look at this and possibly fix it?
If you are not on users@, and to summarize this thread. SVN builds fine on RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw the same problem with our builds.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I am attaching a patch file which I used to change utf.c in the head revision to get things to play nice with el4 64bit. "make check" does come back clean with this version.
-Mike
P.S. why isn't "make check" structured so that the -j option to make would work. It would be nice to use multiple threads to speed up the run.
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Tuesday, August 09, 2011 2:56 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com>> wrote:
Ok, I've tracked down which revision caused the problem. It happened in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion. Ever since this change went in I am seeing subversion crash when I compile on 64bit el4.
Just for kicks and giggles I updated to the HEAD revision of http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on rev 1104160, cleaned up the conflicts and built it and viola! No more crashing when built on 64bit el4.
Thanks. Moving the thread to dev@
Can someone look at this and possibly fix it?
If you are not on users@, and to summarize this thread. SVN builds fine on RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw the same problem with our builds.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Dave Huang <kh...@azeotrope.org> writes:
> On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
>> 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.
>
> It's byte-reversed "svn-utf-"
Ah, yes! It's a little-endian machine so the pointer value is the
opposite order to the string.
--
Philip
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Dave Huang <kh...@azeotrope.org> writes:
> On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
>> 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.
>
> It's byte-reversed "svn-utf-"
Ah, yes! It's a little-endian machine so the pointer value is the
opposite order to the string.
--
Philip
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Dave Huang <kh...@azeotrope.org>.
On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
> 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.
It's byte-reversed "svn-utf-"
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: khym@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
> > 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?
3.4.6
> 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 it wasn't, changing the optimization level shouldn't have made a difference. That being said, ldd reports that I am using the correct version.
libapr-1.so.0 => /cos/home/ryttingm/local/lib/libapr-1.so.0 (0x0000002a967b5000)
-Mike
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Aug 10, 2011 at 7:39 PM, David Chapman <dc...@acm.org> wrote:
> On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
>>
>> It is set to 1
>>
>> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com>
>> wrote:
>>
>>> <mi...@agilent.com> writes:
>>>
>>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>>> longer crashes.
>>>
>>> That suggests it could be a compiler bug.
>
> Sorry to jump in so late, but I had significant problems with optimization
> for 64-bit executables under CentOS 4.x. If you can't upgrade, I suggest
> dialing down the optimization flags. I had to drop from -O3 to -O2 so that
> Crypto++ 5.5.2 would run, for example. At some point I could drop support
> for RHEL/CentOS 4.x from my client's products and try going back to -O3, but
> the required testing hasn't been real high on the priority list.
>
> Assuming the SVN configuration scripts can distinguish between the releases,
> I suspect that changing the default optimization flags for RHEL 4.x will be
> simpler than trying to fix the new UTF-8 code. Have you tried intermediate
> levels of optimization? We went to production with -O2, so it's not as if
> all 64-bit optimizations were broken.
That kind of manipulation would normally be done by setting "CFLAGS"
in the the RPM packaging's .spec files. You may notice that Red Hat
gave up on backporting contemporary subversion releases *years* ago,
and even RPMforge (to which I contribute on this) is only now about
to have 1.6.17 on RHEL 5, because I'm personally testing it.
If you've got RHEL 4 or CentOS 4 or whatever environments to test
with, you're quite welcome to my notes. I don't personally care to
spend unpaid development effort on such an old release, especially
when RHEL 6 is out and active and far more compatible.
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I tried running -O2 and -O1, both were crashing as well. Only completely disabling optimizations will cause the segfault to stop.
-----Original Message-----
From: David Chapman [mailto:dcchapman@acm.org]
Sent: Wednesday, August 10, 2011 5:39 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.martin@wandisco.com; markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com> wrote:
>
>> <mi...@agilent.com> writes:
>>
>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>> longer crashes.
>> That suggests it could be a compiler bug.
Sorry to jump in so late, but I had significant problems with optimization for 64-bit executables under CentOS 4.x. If you can't upgrade, I suggest dialing down the optimization flags. I had to drop from -O3 to -O2 so that Crypto++ 5.5.2 would run, for example. At some point I could drop support for RHEL/CentOS 4.x from my client's products and try going back to -O3, but the required testing hasn't been real high on the priority list.
Assuming the SVN configuration scripts can distinguish between the releases, I suspect that changing the default optimization flags for RHEL 4.x will be simpler than trying to fix the new UTF-8 code. Have you tried intermediate levels of optimization? We went to production with -O2, so it's not as if all 64-bit optimizations were broken.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Wed, Aug 10, 2011 at 7:39 PM, David Chapman <dc...@acm.org> wrote:
> On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
>>
>> It is set to 1
>>
>> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com>
>> wrote:
>>
>>> <mi...@agilent.com> writes:
>>>
>>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>>> longer crashes.
>>>
>>> That suggests it could be a compiler bug.
>
> Sorry to jump in so late, but I had significant problems with optimization
> for 64-bit executables under CentOS 4.x. If you can't upgrade, I suggest
> dialing down the optimization flags. I had to drop from -O3 to -O2 so that
> Crypto++ 5.5.2 would run, for example. At some point I could drop support
> for RHEL/CentOS 4.x from my client's products and try going back to -O3, but
> the required testing hasn't been real high on the priority list.
>
> Assuming the SVN configuration scripts can distinguish between the releases,
> I suspect that changing the default optimization flags for RHEL 4.x will be
> simpler than trying to fix the new UTF-8 code. Have you tried intermediate
> levels of optimization? We went to production with -O2, so it's not as if
> all 64-bit optimizations were broken.
That kind of manipulation would normally be done by setting "CFLAGS"
in the the RPM packaging's .spec files. You may notice that Red Hat
gave up on backporting contemporary subversion releases *years* ago,
and even RPMforge (to which I contribute on this) is only now about
to have 1.6.17 on RHEL 5, because I'm personally testing it.
If you've got RHEL 4 or CentOS 4 or whatever environments to test
with, you're quite welcome to my notes. I don't personally care to
spend unpaid development effort on such an old release, especially
when RHEL 6 is out and active and far more compatible.
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I tried running -O2 and -O1, both were crashing as well. Only completely disabling optimizations will cause the segfault to stop.
-----Original Message-----
From: David Chapman [mailto:dcchapman@acm.org]
Sent: Wednesday, August 10, 2011 5:39 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.martin@wandisco.com; markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com> wrote:
>
>> <mi...@agilent.com> writes:
>>
>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>> longer crashes.
>> That suggests it could be a compiler bug.
Sorry to jump in so late, but I had significant problems with optimization for 64-bit executables under CentOS 4.x. If you can't upgrade, I suggest dialing down the optimization flags. I had to drop from -O3 to -O2 so that Crypto++ 5.5.2 would run, for example. At some point I could drop support for RHEL/CentOS 4.x from my client's products and try going back to -O3, but the required testing hasn't been real high on the priority list.
Assuming the SVN configuration scripts can distinguish between the releases, I suspect that changing the default optimization flags for RHEL 4.x will be simpler than trying to fix the new UTF-8 code. Have you tried intermediate levels of optimization? We went to production with -O2, so it's not as if all 64-bit optimizations were broken.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by David Chapman <dc...@acm.org>.
On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com> wrote:
>
>> <mi...@agilent.com> writes:
>>
>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>> longer crashes.
>> That suggests it could be a compiler bug.
Sorry to jump in so late, but I had significant problems with
optimization for 64-bit executables under CentOS 4.x. If you can't
upgrade, I suggest dialing down the optimization flags. I had to drop
from -O3 to -O2 so that Crypto++ 5.5.2 would run, for example. At some
point I could drop support for RHEL/CentOS 4.x from my client's products
and try going back to -O3, but the required testing hasn't been real
high on the priority list.
Assuming the SVN configuration scripts can distinguish between the
releases, I suspect that changing the default optimization flags for
RHEL 4.x will be simpler than trying to fix the new UTF-8 code. Have
you tried intermediate levels of optimization? We went to production
with -O2, so it's not as if all 64-bit optimizations were broken.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I did. It didn't help.
-Mike
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Monday, August 22, 2011 10:48 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.martin@wandisco.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Michael, did you ever get a chance trying the -fno-strict-aliasing flag rather than removing all optimizations?
On Mon, Aug 22, 2011 at 12:43 PM, <mi...@agilent.com>> wrote:
No luck, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com<ma...@wandisco.com>]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com<ma...@gmail.com>; dev@subversion.apache.org<ma...@subversion.apache.org>; users@subversion.apache.org<ma...@subversion.apache.org>
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
<mi...@agilent.com>> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL; static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really want "volatile pointers to data". Perhaps we should do something similar to svn_cache_config.c. Would you try this patch built with optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void *
+volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I did. It didn't help.
-Mike
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Monday, August 22, 2011 10:48 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: philip.martin@wandisco.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Michael, did you ever get a chance trying the -fno-strict-aliasing flag rather than removing all optimizations?
On Mon, Aug 22, 2011 at 12:43 PM, <mi...@agilent.com>> wrote:
No luck, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com<ma...@wandisco.com>]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com<ma...@gmail.com>; dev@subversion.apache.org<ma...@subversion.apache.org>; users@subversion.apache.org<ma...@subversion.apache.org>
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
<mi...@agilent.com>> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL; static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really want "volatile pointers to data". Perhaps we should do something similar to svn_cache_config.c. Would you try this patch built with optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void *
+volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
Michael, did you ever get a chance trying the -fno-strict-aliasing flag
rather than removing all optimizations?
On Mon, Aug 22, 2011 at 12:43 PM, <mi...@agilent.com> wrote:
> No luck, still crashing.
>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: Monday, August 22, 2011 10:23 AM
> To: RYTTING,MICHAEL (A-ColSprings,ex1)
> Cc: markphip@gmail.com; dev@subversion.apache.org;
> users@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
> <mi...@agilent.com> writes:
>
> > It is set to 1
> >>
> >> 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.
>
> I wonder if it is connected to this APR bug:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
>
> In subversion/libsvn_subr/utf.c we declare
>
> static volatile void *xlat_ntou_static_handle = NULL; static volatile void
> *xlat_uton_static_handle = NULL;
>
> that is "pointers to volatile data", as required by APR, but we really want
> "volatile pointers to data". Perhaps we should do something similar to
> svn_cache_config.c. Would you try this patch built with optimisations
> enabled:
>
> Index: subversion/libsvn_subr/utf.c
> ===================================================================
> --- subversion/libsvn_subr/utf.c (revision 1160136)
> +++ subversion/libsvn_subr/utf.c (working copy)
> @@ -90,8 +90,8 @@
> * using atomic xchange ops, i.e. without further thread synchronization.
> * If the respective item is NULL, fallback to hash lookup.
> */
> -static volatile void *xlat_ntou_static_handle = NULL; -static volatile
> void *xlat_uton_static_handle = NULL;
> +static void * volatile xlat_ntou_static_handle = NULL; static void *
> +volatile xlat_uton_static_handle = NULL;
>
> /* Clean up the xlate handle cache. */
> static apr_status_t
> @@ -182,11 +182,11 @@
> * the caller.
> */
> static APR_INLINE void*
> -atomic_swap(volatile void **mem, void *new_value)
> +atomic_swap(void * volatile * mem, void *new_value)
> {
> #if APR_HAS_THREADS
> #if APR_VERSION_AT_LEAST(1,3,0)
> - return apr_atomic_xchgptr(mem, new_value);
> + return apr_atomic_xchgptr((volatile void **)mem, new_value);
> #else
> /* old APRs don't support atomic swaps. Simply return the
> * input to the caller for further proccessing. */
>
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
Michael, did you ever get a chance trying the -fno-strict-aliasing flag
rather than removing all optimizations?
On Mon, Aug 22, 2011 at 12:43 PM, <mi...@agilent.com> wrote:
> No luck, still crashing.
>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: Monday, August 22, 2011 10:23 AM
> To: RYTTING,MICHAEL (A-ColSprings,ex1)
> Cc: markphip@gmail.com; dev@subversion.apache.org;
> users@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
> <mi...@agilent.com> writes:
>
> > It is set to 1
> >>
> >> 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.
>
> I wonder if it is connected to this APR bug:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
>
> In subversion/libsvn_subr/utf.c we declare
>
> static volatile void *xlat_ntou_static_handle = NULL; static volatile void
> *xlat_uton_static_handle = NULL;
>
> that is "pointers to volatile data", as required by APR, but we really want
> "volatile pointers to data". Perhaps we should do something similar to
> svn_cache_config.c. Would you try this patch built with optimisations
> enabled:
>
> Index: subversion/libsvn_subr/utf.c
> ===================================================================
> --- subversion/libsvn_subr/utf.c (revision 1160136)
> +++ subversion/libsvn_subr/utf.c (working copy)
> @@ -90,8 +90,8 @@
> * using atomic xchange ops, i.e. without further thread synchronization.
> * If the respective item is NULL, fallback to hash lookup.
> */
> -static volatile void *xlat_ntou_static_handle = NULL; -static volatile
> void *xlat_uton_static_handle = NULL;
> +static void * volatile xlat_ntou_static_handle = NULL; static void *
> +volatile xlat_uton_static_handle = NULL;
>
> /* Clean up the xlate handle cache. */
> static apr_status_t
> @@ -182,11 +182,11 @@
> * the caller.
> */
> static APR_INLINE void*
> -atomic_swap(volatile void **mem, void *new_value)
> +atomic_swap(void * volatile * mem, void *new_value)
> {
> #if APR_HAS_THREADS
> #if APR_VERSION_AT_LEAST(1,3,0)
> - return apr_atomic_xchgptr(mem, new_value);
> + return apr_atomic_xchgptr((volatile void **)mem, new_value);
> #else
> /* old APRs don't support atomic swaps. Simply return the
> * input to the caller for further proccessing. */
>
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
No luck, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
<mi...@agilent.com> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL; static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really want "volatile pointers to data". Perhaps we should do something similar to svn_cache_config.c. Would you try this patch built with optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void *
+volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
No luck, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Monday, August 22, 2011 10:23 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
<mi...@agilent.com> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL; static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really want "volatile pointers to data". Perhaps we should do something similar to svn_cache_config.c. Would you try this patch built with optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL; -static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL; static void *
+volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
<mi...@agilent.com> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL;
static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really
want "volatile pointers to data". Perhaps we should do something
similar to svn_cache_config.c. Would you try this patch built with
optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL;
-static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL;
+static void * volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by David Chapman <dc...@acm.org>.
On 8/10/2011 4:12 PM, michael_rytting@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Martin"<ph...@wandisco.com> wrote:
>
>> <mi...@agilent.com> writes:
>>
>>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>>> longer crashes.
>> That suggests it could be a compiler bug.
Sorry to jump in so late, but I had significant problems with
optimization for 64-bit executables under CentOS 4.x. If you can't
upgrade, I suggest dialing down the optimization flags. I had to drop
from -O3 to -O2 so that Crypto++ 5.5.2 would run, for example. At some
point I could drop support for RHEL/CentOS 4.x from my client's products
and try going back to -O3, but the required testing hasn't been real
high on the priority list.
Assuming the SVN configuration scripts can distinguish between the
releases, I suspect that changing the default optimization flags for
RHEL 4.x will be simpler than trying to fix the new UTF-8 code. Have
you tried intermediate levels of optimization? We went to production
with -O2, so it's not as if all 64-bit optimizations were broken.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
<mi...@agilent.com> writes:
> It is set to 1
>>
>> 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.
I wonder if it is connected to this APR bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50731
In subversion/libsvn_subr/utf.c we declare
static volatile void *xlat_ntou_static_handle = NULL;
static volatile void *xlat_uton_static_handle = NULL;
that is "pointers to volatile data", as required by APR, but we really
want "volatile pointers to data". Perhaps we should do something
similar to svn_cache_config.c. Would you try this patch built with
optimisations enabled:
Index: subversion/libsvn_subr/utf.c
===================================================================
--- subversion/libsvn_subr/utf.c (revision 1160136)
+++ subversion/libsvn_subr/utf.c (working copy)
@@ -90,8 +90,8 @@
* using atomic xchange ops, i.e. without further thread synchronization.
* If the respective item is NULL, fallback to hash lookup.
*/
-static volatile void *xlat_ntou_static_handle = NULL;
-static volatile void *xlat_uton_static_handle = NULL;
+static void * volatile xlat_ntou_static_handle = NULL;
+static void * volatile xlat_uton_static_handle = NULL;
/* Clean up the xlate handle cache. */
static apr_status_t
@@ -182,11 +182,11 @@
* the caller.
*/
static APR_INLINE void*
-atomic_swap(volatile void **mem, void *new_value)
+atomic_swap(void * volatile * mem, void *new_value)
{
#if APR_HAS_THREADS
#if APR_VERSION_AT_LEAST(1,3,0)
- return apr_atomic_xchgptr(mem, new_value);
+ return apr_atomic_xchgptr((volatile void **)mem, new_value);
#else
/* old APRs don't support atomic swaps. Simply return the
* input to the caller for further proccessing. */
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
It is set to 1
On Aug 10, 2011, at 3:51 PM, "Philip Martin" <ph...@wandisco.com> wrote:
> <mi...@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
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Dave Huang <kh...@azeotrope.org>.
On Aug 10, 2011, at 4:51 PM, Philip Martin wrote:
> 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.
It's byte-reversed "svn-utf-"
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: khym@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 35 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
> > 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?
3.4.6
> 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 it wasn't, changing the optimization level shouldn't have made a difference. That being said, ldd reports that I am using the correct version.
libapr-1.so.0 => /cos/home/ryttingm/local/lib/libapr-1.so.0 (0x0000002a967b5000)
-Mike
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
It is set to 1
On Aug 10, 2011, at 3:51 PM, "Philip Martin" <ph...@wandisco.com> wrote:
> <mi...@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
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Blair Zajac <bl...@orcaware.com>.
On Aug 11, 2011, at 8:32 AM, <mi...@agilent.com> <mi...@agilent.com> wrote:
> No luck with that option, still crashing.
Try running the process under valgrind to see if it finds anything.
Blair
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Blair Zajac <bl...@orcaware.com>.
On Aug 11, 2011, at 8:32 AM, <mi...@agilent.com> <mi...@agilent.com> wrote:
> No luck with that option, still crashing.
Try running the process under valgrind to see if it finds anything.
Blair
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
No luck with that option, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Wednesday, August 10, 2011 4:20 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Philip Martin <ph...@wandisco.com> writes:
> <mi...@agilent.com> writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>> longer crashes.
>
> That suggests it could be a compiler bug.
The other flag you could try is to enable optimisation but to use -fno-strict-aliasing.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
No luck with that option, still crashing.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Wednesday, August 10, 2011 4:20 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: markphip@gmail.com; dev@subversion.apache.org; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Philip Martin <ph...@wandisco.com> writes:
> <mi...@agilent.com> writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>> longer crashes.
>
> That suggests it could be a compiler bug.
The other flag you could try is to enable optimisation but to use -fno-strict-aliasing.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> <mi...@agilent.com> writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>> longer crashes.
>
> That suggests it could be a compiler bug.
The other flag you could try is to enable optimisation but to use
-fno-strict-aliasing.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> <mi...@agilent.com> writes:
>
>> If I disable optimizations by doing "make CFLAGS=-O0" the program no
>> longer crashes.
>
> That suggests it could be a compiler bug.
The other flag you could try is to enable optimisation but to use
-fno-strict-aliasing.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
<mi...@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
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
<mi...@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
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Branko Čibej <br...@xbc.nu>.
On 16.08.2011 17:25, Mark Phippard wrote:
> Where do we stand on this? I have not seen anyone propose the obvious
> fix which would be to reverse the commit that caused the problem. Do
> we really need this optimization if it can segfault with the wrong
> compiler settings?
Has anyone tried compiling with -fno-strict-aliasing? What we're seeing
here is clearly a compiler bug, and GCC did have trouble with strict
aliasing bugs at some point.
-- Brane
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
Disabling optimizations is definitely an option. I should check to see if disabling optimizations just for the one problem file makes the issue go away. No reason to disable optimizations for all files if necessary.
We have decided to only compile for 32bit and use that on all our 32 and 64 bit redhat systems. So from our perspective this issue is closed.
-----Original Message-----
From: Hyrum K Wright [mailto:hyrum.wright@wandisco.com]
Sent: Tuesday, August 16, 2011 10:56 AM
To: Mark Phippard
Cc: dev@subversion.apache.org; philip.martin@wandisco.com; RYTTING,MICHAEL (A-ColSprings,ex1)
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Tue, Aug 16, 2011 at 10:25 AM, Mark Phippard <ma...@gmail.com> wrote:
> Where do we stand on this? I have not seen anyone propose the obvious
> fix which would be to reverse the commit that caused the problem. Do
> we really need this optimization if it can segfault with the wrong compiler settings?
> As mentioned before, we saw this same problem in the Linux RPM's that
> we provide. Currently we are working around it by doing the build on
> RHEL 5 and dropping support for RHEL 4, but obviously the preferred
> solution for us would be to continue to support RHEL 4.
I don't think we should revert this change, as it's a symptom of a compiler bug. If my understanding of this thread is correct, you could just disable optimizations for your RHEL 4 builds, and things should work, no?
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Tue, Aug 16, 2011 at 10:25 AM, Mark Phippard <ma...@gmail.com> wrote:
> Where do we stand on this? I have not seen anyone propose the obvious fix
> which would be to reverse the commit that caused the problem. Do we really
> need this optimization if it can segfault with the wrong compiler settings?
> As mentioned before, we saw this same problem in the Linux RPM's that we
> provide. Currently we are working around it by doing the build on RHEL 5
> and dropping support for RHEL 4, but obviously the preferred solution for us
> would be to continue to support RHEL 4.
I don't think we should revert this change, as it's a symptom of a
compiler bug. If my understanding of this thread is correct, you
could just disable optimizations for your RHEL 4 builds, and things
should work, no?
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
Where do we stand on this? I have not seen anyone propose the obvious fix
which would be to reverse the commit that caused the problem. Do we really
need this optimization if it can segfault with the wrong compiler settings?
As mentioned before, we saw this same problem in the Linux RPM's that we
provide. Currently we are working around it by doing the build on RHEL 5
and dropping support for RHEL 4, but obviously the preferred solution for us
would be to continue to support RHEL 4.
Mark
On Wed, Aug 10, 2011 at 3:52 PM, <mi...@agilent.com> wrote:
> I am attaching a stack trace with symbols enabled.
>
> I'm using gcc. The default in the makefile.
>
> I am using the apr that you get from the get-deps.sh script.
> APR_HAS_THREADS is defined.
>
> If I disable optimizations by doing "make CFLAGS=-O0" the program no longer
> crashes.
>
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: Tuesday, August 09, 2011 3:34 PM
> To: Mark Phippard
> Cc: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development;
> users@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
> Mark Phippard <ma...@gmail.com> writes:
>
> > On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
> >
> >> ** **
> >>
> >> Ok, I’ve tracked down which revision caused the problem. It happened
> >> in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8
> conversion.
> >> Ever since this change went in I am seeing subversion crash when I
> >> compile on 64bit el4.****
> >>
> >> ** **
> >>
> >> Just for kicks and giggles I updated to the HEAD revision of
> >> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse
> >> merge on rev 1104160, cleaned up the conflicts and built it and
> >> viola! No more crashing when built on 64bit el4.
> >>
> >
> > Thanks. Moving the thread to dev@
> >
> > Can someone look at this and possibly fix it?
> >
> > If you are not on users@, and to summarize this thread. SVN builds
> > fine on RHEL 4 64-bit but crashes immediately on any command, even svn
> > help. I saw the same problem with our builds.
>
> It could be a compiler/optimiser bug. Which compiler are you using?
> Can you provide a stack trace of the crash (with debug symbols please)?
> Does the crash go away if you compile utf.c without optimisation? Which
> version of APR are you using? Is APR_HAS_THREADS defined in apr.h?
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I am attaching a stack trace with symbols enabled.
I'm using gcc. The default in the makefile.
I am using the apr that you get from the get-deps.sh script. APR_HAS_THREADS is defined.
If I disable optimizations by doing "make CFLAGS=-O0" the program no longer crashes.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Tuesday, August 09, 2011 3:34 PM
To: Mark Phippard
Cc: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
>
>> ** **
>>
>> Ok, I’ve tracked down which revision caused the problem. It happened
>> in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
>> Ever since this change went in I am seeing subversion crash when I
>> compile on 64bit el4.****
>>
>> ** **
>>
>> Just for kicks and giggles I updated to the HEAD revision of
>> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse
>> merge on rev 1104160, cleaned up the conflicts and built it and
>> viola! No more crashing when built on 64bit el4.
>>
>
> Thanks. Moving the thread to dev@
>
> Can someone look at this and possibly fix it?
>
> If you are not on users@, and to summarize this thread. SVN builds
> fine on RHEL 4 64-bit but crashes immediately on any command, even svn
> help. I saw the same problem with our builds.
It could be a compiler/optimiser bug. Which compiler are you using?
Can you provide a stack trace of the crash (with debug symbols please)?
Does the crash go away if you compile utf.c without optimisation? Which version of APR are you using? Is APR_HAS_THREADS defined in apr.h?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
I am attaching a stack trace with symbols enabled.
I'm using gcc. The default in the makefile.
I am using the apr that you get from the get-deps.sh script. APR_HAS_THREADS is defined.
If I disable optimizations by doing "make CFLAGS=-O0" the program no longer crashes.
-----Original Message-----
From: Philip Martin [mailto:philip.martin@wandisco.com]
Sent: Tuesday, August 09, 2011 3:34 PM
To: Mark Phippard
Cc: RYTTING,MICHAEL (A-ColSprings,ex1); Subversion Development; users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
>
>> ** **
>>
>> Ok, I’ve tracked down which revision caused the problem. It happened
>> in rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
>> Ever since this change went in I am seeing subversion crash when I
>> compile on 64bit el4.****
>>
>> ** **
>>
>> Just for kicks and giggles I updated to the HEAD revision of
>> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse
>> merge on rev 1104160, cleaned up the conflicts and built it and
>> viola! No more crashing when built on 64bit el4.
>>
>
> Thanks. Moving the thread to dev@
>
> Can someone look at this and possibly fix it?
>
> If you are not on users@, and to summarize this thread. SVN builds
> fine on RHEL 4 64-bit but crashes immediately on any command, even svn
> help. I saw the same problem with our builds.
It could be a compiler/optimiser bug. Which compiler are you using?
Can you provide a stack trace of the crash (with debug symbols please)?
Does the crash go away if you compile utf.c without optimisation? Which version of APR are you using? Is APR_HAS_THREADS defined in apr.h?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
>
>> ** **
>>
>> Ok, I’ve tracked down which revision caused the problem. It happened in
>> rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
>> Ever since this change went in I am seeing subversion crash when I compile
>> on 64bit el4.****
>>
>> ** **
>>
>> Just for kicks and giggles I updated to the HEAD revision of
>> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on
>> rev 1104160, cleaned up the conflicts and built it and viola! No more
>> crashing when built on 64bit el4.
>>
>
> Thanks. Moving the thread to dev@
>
> Can someone look at this and possibly fix it?
>
> If you are not on users@, and to summarize this thread. SVN builds fine on
> RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw
> the same problem with our builds.
It could be a compiler/optimiser bug. Which compiler are you using?
Can you provide a stack trace of the crash (with debug symbols please)?
Does the crash go away if you compile utf.c without optimisation? Which
version of APR are you using? Is APR_HAS_THREADS defined in apr.h?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Philip Martin <ph...@wandisco.com>.
Mark Phippard <ma...@gmail.com> writes:
> On Tue, Aug 9, 2011 at 4:49 PM, <mi...@agilent.com> wrote:
>
>> ** **
>>
>> Ok, I’ve tracked down which revision caused the problem. It happened in
>> rev 1104160. Stefan2 made a change to utf.c to speed up UTF8 conversion.
>> Ever since this change went in I am seeing subversion crash when I compile
>> on 64bit el4.****
>>
>> ** **
>>
>> Just for kicks and giggles I updated to the HEAD revision of
>> http://svn.apache.org/repos/asf/subversion/trunk. Did a reverse merge on
>> rev 1104160, cleaned up the conflicts and built it and viola! No more
>> crashing when built on 64bit el4.
>>
>
> Thanks. Moving the thread to dev@
>
> Can someone look at this and possibly fix it?
>
> If you are not on users@, and to summarize this thread. SVN builds fine on
> RHEL 4 64-bit but crashes immediately on any command, even svn help. I saw
> the same problem with our builds.
It could be a compiler/optimiser bug. Which compiler are you using?
Can you provide a stack trace of the crash (with debug symbols please)?
Does the crash go away if you compile utf.c without optimisation? Which
version of APR are you using? Is APR_HAS_THREADS defined in apr.h?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com