You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@apache.org> on 2019/12/31 09:33:45 UTC
OpenBSD buildbot
The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
error deep inside the Ruby runtime (most likely caused by misaligned
memory access). This makes rather less useful than it could be.
I'm wondering if it would make sense to just skip building and testing
the Ruby bindings there, and perhaps make a separate build configuration
that tests just the Ruby bindings on OpenBSD.
-- Brane
Re: OpenBSD buildbot
Posted by Stefan Sperling <st...@stsp.name>.
On Tue, Dec 31, 2019 at 11:35:22AM -0500, James McCoy wrote:
> On Tue, Dec 31, 2019 at 05:04:00PM +0100, Stefan Sperling wrote:
> > On Tue, Dec 31, 2019 at 04:27:06PM +0100, Branko Čibej wrote:
> > > On 31.12.2019 16:05, Stefan Sperling wrote:
> > > > On Tue, Dec 31, 2019 at 10:33:45AM +0100, Branko Čibej wrote:
> > > >> The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
> > > >> error deep inside the Ruby runtime (most likely caused by misaligned
> > > >> memory access). This makes rather less useful than it could be.
> > > >>
> > > >> I'm wondering if it would make sense to just skip building and testing
> > > >> the Ruby bindings there, and perhaps make a separate build configuration
> > > >> that tests just the Ruby bindings on OpenBSD.
> > > > The problem cannot happen during every run. AFAIK it occurs during
> > > > the build of Ruby itself, not the SVN ruby bindings build or tests.
> > > > And Ruby itself will only be recompiled if Makefile.svn is changed
> > > > or the system is rebooted (the build files live in a ramdisk).
> > >
> > > Oh ... I seem to have misunderstood the issue. So it's actually even
> > > worse and the tests are held hostage to a depenency build. Would there
> > > be a way to completely detach the building of dependencies from building
> > > and testing Subversion? E.g., the dependencies could be installed to a
> > > more presistent location and only rebuilt if their sources changed.
> >
> > Honestly instead of working on that I'd rather put effort into fixing the
> > underlying Ruby issue.
>
> Agreed, but in build 472 the bus error was when running SVN's configure
> to determine if Ruby had specific functionality.
>
> https://ci.apache.org/builders/svn-bb-openbsd/builds/472/steps/Build/logs/stdio
Oh. I am quite certain this never happened before.
Re: OpenBSD buildbot
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 31, 2019 at 03:51:16PM -0500, Nathan Hartman wrote:
> On Tue, Dec 31, 2019 at 11:35 AM James McCoy <ja...@jamessan.com> wrote:
> > [NOTE]
> > You may have encountered a bug in the Ruby interpreter or extension libraries.
> > Bug reports are welcome.
> > For details: http://www.ruby-lang.org/bugreport.html
>
> Out of curiosity, has anyone been reporting these to the ruby devs?
>
> Nathan
Yes, I have mentioned this to Jeremy Evans in person.
We didn't get a conclusive result but I'll try to pick that conversation
back up.
Re: OpenBSD buildbot
Posted by Nathan Hartman <ha...@gmail.com>.
On Tue, Dec 31, 2019 at 11:35 AM James McCoy <ja...@jamessan.com> wrote:
> [NOTE]
> You may have encountered a bug in the Ruby interpreter or extension libraries.
> Bug reports are welcome.
> For details: http://www.ruby-lang.org/bugreport.html
Out of curiosity, has anyone been reporting these to the ruby devs?
Nathan
Re: OpenBSD buildbot
Posted by James McCoy <ja...@jamessan.com>.
On Tue, Dec 31, 2019 at 05:04:00PM +0100, Stefan Sperling wrote:
> On Tue, Dec 31, 2019 at 04:27:06PM +0100, Branko Čibej wrote:
> > On 31.12.2019 16:05, Stefan Sperling wrote:
> > > On Tue, Dec 31, 2019 at 10:33:45AM +0100, Branko Čibej wrote:
> > >> The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
> > >> error deep inside the Ruby runtime (most likely caused by misaligned
> > >> memory access). This makes rather less useful than it could be.
> > >>
> > >> I'm wondering if it would make sense to just skip building and testing
> > >> the Ruby bindings there, and perhaps make a separate build configuration
> > >> that tests just the Ruby bindings on OpenBSD.
> > > The problem cannot happen during every run. AFAIK it occurs during
> > > the build of Ruby itself, not the SVN ruby bindings build or tests.
> > > And Ruby itself will only be recompiled if Makefile.svn is changed
> > > or the system is rebooted (the build files live in a ramdisk).
> >
> > Oh ... I seem to have misunderstood the issue. So it's actually even
> > worse and the tests are held hostage to a depenency build. Would there
> > be a way to completely detach the building of dependencies from building
> > and testing Subversion? E.g., the dependencies could be installed to a
> > more presistent location and only rebuilt if their sources changed.
>
> Honestly instead of working on that I'd rather put effort into fixing the
> underlying Ruby issue.
Agreed, but in build 472 the bus error was when running SVN's configure
to determine if Ruby had specific functionality.
https://ci.apache.org/builders/svn-bb-openbsd/builds/472/steps/Build/logs/stdio
[[[
checking rb_hash_foreach... /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/specification.rb:10: [BUG] Bus Error at 0x00000036b1b5d3b8
ruby 2.4.4p296 (2018-03-28 revision 63013) [sparc64-openbsd6.6]
-- Control frame information -----------------------------------------------
c:0008 p:---- s:0033 e:000032 CFUNC :require
c:0007 p:0008 s:0028 e:000027 TOP /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/specification.rb:10 [FINISH]
c:0006 p:---- s:0025 e:000024 CFUNC :require
c:0005 p:1618 s:0020 E:000e10 CLASS /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems.rb:1335
c:0004 p:0073 s:0015 e:000014 TOP /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems.rb:116 [FINISH]
c:0003 p:---- s:0011 e:000010 CFUNC :require
c:0002 p:0016 s:0006 e:000005 TOP <internal:gem_prelude>:4 [FINISH]
c:0001 p:0000 s:0003 E:000de0 (none) [FINISH]
-- Ruby level backtrace information ----------------------------------------
<internal:gem_prelude>:4:in `<internal:gem_prelude>'
<internal:gem_prelude>:4:in `require'
/var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems.rb:116:in `<top (required)>'
/var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems.rb:1335:in `<module:Gem>'
/var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems.rb:1335:in `require'
/var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/specification.rb:10:in `<top (required)>'
/var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/specification.rb:10:in `require'
-- Other runtime information -----------------------------------------------
* Loaded script: /var/buildslave/svn-bb-openbsd/prefix/ruby/bin/ruby
* Loaded features:
0 enumerator.so
1 thread.rb
2 rational.so
3 complex.so
4 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/sparc64-openbsd6.6/enc/encdb.so
5 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/sparc64-openbsd6.6/enc/trans/transdb.so
6 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/unicode_normalize.rb
7 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/sparc64-openbsd6.6/rbconfig.rb
8 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/compatibility.rb
9 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/defaults.rb
10 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/deprecate.rb
11 /var/buildslave/svn-bb-openbsd/prefix/ruby/lib/ruby/2.4.0/rubygems/errors.rb
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html
Abort trap (core dumped)
no
configure: WARNING: The detected Ruby is too old for Subversion to use
configure: WARNING: A Ruby which has rb_hash_foreach is required to use the
configure: WARNING: Subversion Ruby bindings
configure: WARNING: Upgrade to the official 1.8.2 release, or later
]]]
Cheers,
--
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Re: OpenBSD buildbot
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 31, 2019 at 04:27:06PM +0100, Branko Čibej wrote:
> On 31.12.2019 16:05, Stefan Sperling wrote:
> > On Tue, Dec 31, 2019 at 10:33:45AM +0100, Branko Čibej wrote:
> >> The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
> >> error deep inside the Ruby runtime (most likely caused by misaligned
> >> memory access). This makes rather less useful than it could be.
> >>
> >> I'm wondering if it would make sense to just skip building and testing
> >> the Ruby bindings there, and perhaps make a separate build configuration
> >> that tests just the Ruby bindings on OpenBSD.
> > The problem cannot happen during every run. AFAIK it occurs during
> > the build of Ruby itself, not the SVN ruby bindings build or tests.
> > And Ruby itself will only be recompiled if Makefile.svn is changed
> > or the system is rebooted (the build files live in a ramdisk).
>
> Oh ... I seem to have misunderstood the issue. So it's actually even
> worse and the tests are held hostage to a depenency build. Would there
> be a way to completely detach the building of dependencies from building
> and testing Subversion? E.g., the dependencies could be installed to a
> more presistent location and only rebuilt if their sources changed.
Honestly instead of working on that I'd rather put effort into fixing the
underlying Ruby issue.
Re: OpenBSD buildbot
Posted by Branko Čibej <br...@apache.org>.
On 31.12.2019 16:05, Stefan Sperling wrote:
> On Tue, Dec 31, 2019 at 10:33:45AM +0100, Branko Čibej wrote:
>> The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
>> error deep inside the Ruby runtime (most likely caused by misaligned
>> memory access). This makes rather less useful than it could be.
>>
>> I'm wondering if it would make sense to just skip building and testing
>> the Ruby bindings there, and perhaps make a separate build configuration
>> that tests just the Ruby bindings on OpenBSD.
> The problem cannot happen during every run. AFAIK it occurs during
> the build of Ruby itself, not the SVN ruby bindings build or tests.
> And Ruby itself will only be recompiled if Makefile.svn is changed
> or the system is rebooted (the build files live in a ramdisk).
Oh ... I seem to have misunderstood the issue. So it's actually even
worse and the tests are held hostage to a depenency build. Would there
be a way to completely detach the building of dependencies from building
and testing Subversion? E.g., the dependencies could be installed to a
more presistent location and only rebuilt if their sources changed.
-- Brane
Re: OpenBSD buildbot
Posted by Stefan Sperling <st...@elego.de>.
On Tue, Dec 31, 2019 at 10:33:45AM +0100, Branko Čibej wrote:
> The OpenBSD buildbot seems to have a 50% chance of failing due to a bus
> error deep inside the Ruby runtime (most likely caused by misaligned
> memory access). This makes rather less useful than it could be.
>
> I'm wondering if it would make sense to just skip building and testing
> the Ruby bindings there, and perhaps make a separate build configuration
> that tests just the Ruby bindings on OpenBSD.
The problem cannot happen during every run. AFAIK it occurs during
the build of Ruby itself, not the SVN ruby bindings build or tests.
And Ruby itself will only be recompiled if Makefile.svn is changed
or the system is rebooted (the build files live in a ramdisk).
Re: OpenBSD buildbot
Posted by Paul Hammant <pa...@hammant.org>.
Just change it to retries=5 on some fine-grained basis and stop worrying
about it as long as that fixes it?