You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by mi...@agilent.com on 2011/08/09 00:19:06 UTC
Problems compiling 1.7.0 on redhat el4 64bit
For a while I was downloading and running the development build of subversion 1.7.0. At one revision of the code I started having an issue where svn would immediately segfault. At that time I stopped using 1.7.0 assuming the issue would be fixed before release. Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the same problem. Interestingly enough I can successfully build beta2 on one of our 32bit systems, but I can't use that build on our 64 bit systems because it tries to link against the 32bit version of libmagic.
It's important to note that I don't get any errors compiling the design. It's just that after I install it I get a segfault when I try and run svn. Ironically, if I run svn with no options or invalid options it successfully runs, but as soon as I add a valid option like "svn help" it segfaults. I've spent multiple hours trying to compile with different options to my LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, apr-util, serf, and neon, but it always results in the same problem.
I am using a very vanilla build process.
Wget
Tar
./get-deps.sh
./configure -prefix=$HOME/local
make && make install
As I've noted I have successfully built a development version of 1.7.0 on our 64bit systems in the past.
-Mike
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
Like I've said, I was able to build subversion 1.7.0 on our 64bit systems in the past. The build flow hasn't changed. I've put a lot of time into trying different options to the build flow and I'm pretty sure that isn't the culprit.
As for your second recommendation, it doesn't look like libmagic can be disabled. The configure script doesn't read the without_libmagic variable anywhere. And the configure script doesn't properly deal with the "no" argument. I just ended up deleting the entire libmagic section in the configure script and built subversion that way. Now at least I can build on a 32bit system and run the 32bit version of svn on our 64bit systems.
-----Original Message-----
From: Stefan Sperling [mailto:stsp@elego.de]
Sent: Tuesday, August 09, 2011 8:35 AM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytting@agilent.com wrote:
> For a while I was downloading and running the development build of subversion 1.7.0. At one revision of the code I started having an issue where svn would immediately segfault. At that time I stopped using 1.7.0 assuming the issue would be fixed before release. Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the same problem. Interestingly enough I can successfully build beta2 on one of our 32bit systems, but I can't use that build on our 64 bit systems because it tries to link against the 32bit version of libmagic.
>
> It's important to note that I don't get any errors compiling the design. It's just that after I install it I get a segfault when I try and run svn. Ironically, if I run svn with no options or invalid options it successfully runs, but as soon as I add a valid option like "svn help" it segfaults. I've spent multiple hours trying to compile with different options to my LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, apr-util, serf, and neon, but it always results in the same problem.
>
> I am using a very vanilla build process.
>
> Wget
> Tar
> ./get-deps.sh
> ./configure -prefix=$HOME/local
> make && make install
>
This is most likely a problem with your build, not with Subversion itself. Maybe your build is getting 32bit and 64bit libraries mixed up?
> As I've noted I have successfully built a development version of 1.7.0 on our 64bit systems in the past.
Note that libmagic support was added quite recently (in alpha2).
Does the problem disappear if you pass the --with-libmagic=no option to configure?
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytting@agilent.com wrote:
> For a while I was downloading and running the development build of subversion 1.7.0. At one revision of the code I started having an issue where svn would immediately segfault. At that time I stopped using 1.7.0 assuming the issue would be fixed before release. Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the same problem. Interestingly enough I can successfully build beta2 on one of our 32bit systems, but I can't use that build on our 64 bit systems because it tries to link against the 32bit version of libmagic.
>
> It's important to note that I don't get any errors compiling the design. It's just that after I install it I get a segfault when I try and run svn. Ironically, if I run svn with no options or invalid options it successfully runs, but as soon as I add a valid option like "svn help" it segfaults. I've spent multiple hours trying to compile with different options to my LD_LIBRARY_PATH/PATH variables and I've tried to mix up how I build apr, apr-util, serf, and neon, but it always results in the same problem.
>
> I am using a very vanilla build process.
>
> Wget
> Tar
> ./get-deps.sh
> ./configure -prefix=$HOME/local
> make && make install
>
This is most likely a problem with your build, not with Subversion
itself. Maybe your build is getting 32bit and 64bit libraries mixed up?
> As I've noted I have successfully built a development version of 1.7.0 on our 64bit systems in the past.
Note that libmagic support was added quite recently (in alpha2).
Does the problem disappear if you pass the --with-libmagic=no
option to configure?
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Aug 8, 2011 at 6:19 PM, <mi...@agilent.com> wrote:
> For a while I was downloading and running the development build of
> subversion 1.7.0. At one revision of the code I started having an issue
> where svn would immediately segfault. At that time I stopped using 1.7.0
> assuming the issue would be fixed before release. Unfortunately I just
> downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> Interestingly enough I can successfully build beta2 on one of our 32bit
> systems, but I can’t use that build on our 64 bit systems because it tries
> to link against the 32bit version of libmagic.****
>
> ** **
>
> It’s important to note that I don’t get any errors compiling the design.
> It’s just that after I install it I get a segfault when I try and run svn.
> Ironically, if I run svn with no options or invalid options it successfully
> runs, but as soon as I add a valid option like “svn help” it segfaults.
> I’ve spent multiple hours trying to compile with different options to my
> LD_LIBRARY_PATH/PATH variables and I’ve tried to mix up how I build apr,
> apr-util, serf, and neon, but it always results in the same problem.****
>
> ** **
>
> I am using a very vanilla build process.****
>
> ** **
>
> Wget****
>
> Tar****
>
> ./get-deps.sh****
>
> ./configure –prefix=$HOME/local****
>
> make && make install****
>
> ** **
>
> As I’ve noted I have successfully built a development version of 1.7.0 on
> our 64bit systems in the past.
>
We see the same problem when compiling our binaries on RHEL 4 64-bit. We
had to switch to building on RHEL 5. I do not have the failing binaries
available to test any more. Maybe it would help if you provided details on
the segfault like a dump or something? I thought the problem was in our
build process so I did not raise the issue and we do not actually support
RHEL 4 anymore so I did not press it.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 9, 2011 at 2:58 PM, Nico Kadel-Garcia <nk...@gmail.com> wrote:
> On Mon, Aug 8, 2011 at 6:19 PM, <mi...@agilent.com> wrote:
> > For a while I was downloading and running the development build of
> > subversion 1.7.0. At one revision of the code I started having an issue
> > where svn would immediately segfault. At that time I stopped using 1.7.0
> > assuming the issue would be fixed before release. Unfortunately I just
> > downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> > Interestingly enough I can successfully build beta2 on one of our 32bit
> > systems, but I can’t use that build on our 64 bit systems because it
> tries
> > to link against the 32bit version of libmagic.
>
> RHEL 4 is, frankly, way too old to support with new tools. It's
> initial release was over six years, and far too many core libraries,
> such as swig and sqlite and python, have not gotten updated to match
> subversion requirements.
>
Whether it is a good idea and whether it ought to work are really two
separate conversations. 1.7 was building fine on RHEL 4 and then stopped
working. Is that a bug that should be fixed? I think so. It might be up
to Michael to track down what caused the breakage though. Like I said, I
also saw this problem but I was able to move to RHEL 5. So I lacked
motivation to solve it on RHEL 4. In my case, I build my own version of all
of the dependencies, the versions that come from Red Hat does not matter to
me. Exception being gcc and libc etc.
--
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
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
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 Mark Phippard <ma...@gmail.com>.
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.
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.
-Mike
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Aug 9, 2011 at 3:24 PM, <mi...@agilent.com> wrote:
> Unfortunately, some of us don't have a choice what version of linux we have
> to run on. I end up compiling almost all the dependencies for subversion
> myself. I guess I'll need to track down exactly what change in the
> development process started breaking things. For now, we have a solution
> where I've compiled on 32bit with support for libmagic manually removed.
>
Did you try building a 64-bit version with the same hack? I would not
expect libmagic to be related to the crashing, but there is some
circumstantial evidence to say it is worth looking at. Most notably, the
support for that feature was added very late in the dev cycle and you said
that RHEL 4 binaries from trunk were working for you until recently.
> As a side note, it would be nice to actually be able to add a
> --without-libmagic and have the configure script work without hacking. The
> release notes even say libmagic is optional, but the way I see it currently,
> the only we the default configure won't use it is if your build machine
> doesn't have libmagic installed.
>
It should be possible to do this, so it is a bug. I think I saw the
developers discussing this on IRC, so I suspect it will be fixed if it does
not work.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
RE: Problems compiling 1.7.0 on redhat el4 64bit
Posted by mi...@agilent.com.
Unfortunately, some of us don't have a choice what version of linux we have to run on. I end up compiling almost all the dependencies for subversion myself. I guess I'll need to track down exactly what change in the development process started breaking things. For now, we have a solution where I've compiled on 32bit with support for libmagic manually removed.
As a side note, it would be nice to actually be able to add a --without-libmagic and have the configure script work without hacking. The release notes even say libmagic is optional, but the way I see it currently, the only we the default configure won't use it is if your build machine doesn't have libmagic installed.
-----Original Message-----
From: Nico Kadel-Garcia [mailto:nkadel@gmail.com]
Sent: Tuesday, August 09, 2011 12:59 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1)
Cc: users@subversion.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Mon, Aug 8, 2011 at 6:19 PM, <mi...@agilent.com> wrote:
> For a while I was downloading and running the development build of
> subversion 1.7.0. At one revision of the code I started having an
> issue where svn would immediately segfault. At that time I stopped
> using 1.7.0 assuming the issue would be fixed before release.
> Unfortunately I just downloaded the beta2 release of 1.7.0 and I'm having the same problem.
> Interestingly enough I can successfully build beta2 on one of our
> 32bit systems, but I can't use that build on our 64 bit systems
> because it tries to link against the 32bit version of libmagic.
RHEL 4 is, frankly, way too old to support with new tools. It's initial release was over six years, and far too many core libraries, such as swig and sqlite and python, have not gotten updated to match subversion requirements.
I'm trying to rebundle an SRPM for 1.6.17 for the RPMforge repository, and no way am I burning the cycles to get it back to RHEL 4. The
1.7.0beta3 releases will compile well enough on RHEL 5, especially if you build from an SRPM for 1.6.x first to get most of the dependencies resolved.
RHEL 5, and Scientific Linux 5, have subversion-1.6.11 available from the upstream vendor. Would that be enough for you?
Re: Problems compiling 1.7.0 on redhat el4 64bit
Posted by Nico Kadel-Garcia <nk...@gmail.com>.
On Mon, Aug 8, 2011 at 6:19 PM, <mi...@agilent.com> wrote:
> For a while I was downloading and running the development build of
> subversion 1.7.0. At one revision of the code I started having an issue
> where svn would immediately segfault. At that time I stopped using 1.7.0
> assuming the issue would be fixed before release. Unfortunately I just
> downloaded the beta2 release of 1.7.0 and I’m having the same problem.
> Interestingly enough I can successfully build beta2 on one of our 32bit
> systems, but I can’t use that build on our 64 bit systems because it tries
> to link against the 32bit version of libmagic.
RHEL 4 is, frankly, way too old to support with new tools. It's
initial release was over six years, and far too many core libraries,
such as swig and sqlite and python, have not gotten updated to match
subversion requirements.
I'm trying to rebundle an SRPM for 1.6.17 for the RPMforge repository,
and no way am I burning the cycles to get it back to RHEL 4. The
1.7.0beta3 releases will compile well enough on RHEL 5, especially if
you build from an SRPM for 1.6.x first to get most of the dependencies
resolved.
RHEL 5, and Scientific Linux 5, have subversion-1.6.11 available from
the upstream vendor. Would that be enough for you?