rsion.apache.org<mailto:users@subversion.apache.org>
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
mailto:michael_rytt...@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 f
Monday, August 22, 2011 10:23 AM
> To: RYTTING,MICHAEL (A-ColSprings,ex1)
> Cc: markp...@gmail.com; d...@subversion.apache.org;
> users@subversion.apache.org
> Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
>
> writes:
>
> > It is set to 1
> >>
>
compiling 1.7.0 on redhat el4 64bit
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 g
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_
On Aug 11, 2011, at 8:32 AM,
wrote:
> No luck with that option, still crashing.
Try running the process under valgrind to see if it finds anything.
Blair
: Problems compiling 1.7.0 on redhat el4 64bit
Philip Martin writes:
> 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 en
> > 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
: philip.mar...@wandisco.com; markp...@gmail.com; d...@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_rytt...@agilent.com wrote:
> It is set to 1
>
> On Aug 10, 2011, at 3:51 PM, "Philip Mar
On Wed, Aug 10, 2011 at 7:39 PM, David Chapman wrote:
> On 8/10/2011 4:12 PM, michael_rytt...@agilent.com wrote:
>>
>> It is set to 1
>>
>> On Aug 10, 2011, at 3:51 PM, "Philip Martin"
>> wrote:
>>
>>> writes:
>>>
If I disable optimizations by doing "make CFLAGS=-O0" the program no
lo
On 8/10/2011 4:12 PM, michael_rytt...@agilent.com wrote:
It is set to 1
On Aug 10, 2011, at 3:51 PM, "Philip Martin" wrote:
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, b
It is set to 1
On Aug 10, 2011, at 3:51 PM, "Philip Martin" wrote:
> 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 versio
Philip Martin writes:
> 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
Dave Huang 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 litt
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 / t
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.
riginal Message-
From: Philip Martin [mailto:philip.mar...@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
Mark Phippard writes:
> On Tue, Aug 9, 2011 at 4:49 PM, 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 whe
On Tue, Aug 9, 2011 at 4:02 PM, 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,
And of course I forget to actually attach the file.
From: Mark Phippard [mailto:markp...@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
It would be nice to use multiple threads to speed up the run.
From: Mark Phippard [mailto:markp...@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, 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.
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
On Tue, Aug 9, 2011 at 3:24 PM, 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 brea
on.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Mon, Aug 8, 2011 at 6:19 PM, 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
On Tue, Aug 9, 2011 at 2:58 PM, Nico Kadel-Garcia wrote:
> On Mon, Aug 8, 2011 at 6:19 PM, 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 tha
On Mon, Aug 8, 2011 at 6:19 PM, 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 be
version.apache.org
Subject: Re: Problems compiling 1.7.0 on redhat el4 64bit
On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytt...@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
On Mon, Aug 08, 2011 at 04:19:06PM -0600, michael_rytt...@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
On Mon, Aug 8, 2011 at 6:19 PM, 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 be
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
30 matches
Mail list logo
