[ruby-core:37588] CI?

[ruby-core:37588] CI?

[Ryan Davis]

Is this an official CI for ruby?

http://59.106.172.211/~chkbuild/ruby-trunk/summary.html

If so... how does one read this?? I can't make sense of it.

[ruby-core:37590] Re: CI?

[NARUSE, Yui]

(2011/06/28 6:28), Ryan Davis wrote:
> Is this an official CI for ruby?

It is mine.
It is the result of chkbuild on FreeBSD 8.2 x86_64.
chkbuild is a CI by akr.
http://cvs.m17n.org/viewcvs/ruby/chkbuild/


> http://59.106.172.211/~chkbuild/ruby-trunk/summary.html
> 
> If so... how does one read this?? I can't make sense of it.

For examle,
20101011T060001Z ruby 1.9.3dev (2010-10-11 trunk 29438) [x64-freebsd8.1] (fbsd81) 2730W 1F0E1S rubyspec:23F1E (diff:test-all)

20101011T060001Z is the time chkdbuild runs from; the link is for the result.
ruby 1.9.3dev (2010-10-11 trunk 29438) [x64-freebsd8.1] is `ruby -v`.
(fbsd81) is the name of this CI.
2730W is the number of warnings of the result.
1F0E1S is the result of test-all; 1 Fail 0 Error 1 Skip.
rubyspec:23F1E is the result of test-rubyspec; 23 Failure 1 Error.
(diff:test-all) is the link to the diff between this result and the previous result.

Anyway, summary.html is too big; I recommend to see recent.html.

We should keep 0F0E, but in current situation on the environment
1F0E46S rubyspec:1F1E is the best result.
If it is increased, it means someone breaks something.

-- 
NARUSE, Yui  <naruse@airemix.jp>

[ruby-core:37600] Re: CI?

[Clifford Heath]

I see quite a few segfault bugs being reported.

Does anyone use Purify, valgrind, or any such tools?
I've used Purify extensively in the past, and regard it
as an essential tool for any C or C++ development.
Such tools should be *mandatory* for any widely-used
code-bases.

Memory corruption bugs are often innocuous, causing
no effects until a slight change, that can be years after,
causes random and unrelated crashes to appear
seemingly out of the blue. Even just re-linking with an
updated C library, adding a function that affects memory
layout (so a bug in *another* function shows up), and
basically the tiniest changes, can trigger a fault to show
itself.

The only way to effectively prevent such bugs is a tool
like Purify, which isolates the source of a potential
error, possibly long before the subsequent crash.
Purify is much better than valgrind, by the way. It rewrites
your object code (including all system shared libraries)
such that every memory reference is checked; no bounds
overflows, no read-before-set errors, etc. An incredible and
under-utilised tool...

Clifford Heath.

On 28/06/2011, at 7:45 AM, NARUSE, Yui wrote:

> (2011/06/28 6:28), Ryan Davis wrote:
>> Is this an official CI for ruby?
>
> It is mine.
> It is the result of chkbuild on FreeBSD 8.2 x86_64.
> chkbuild is a CI by akr.
> http://cvs.m17n.org/viewcvs/ruby/chkbuild/
>
>
>> http://59.106.172.211/~chkbuild/ruby-trunk/summary.html
>>
>> If so... how does one read this?? I can't make sense of it.
>
> For examle,
> 20101011T060001Z ruby 1.9.3dev (2010-10-11 trunk 29438) [x64- 
> freebsd8.1] (fbsd81) 2730W 1F0E1S rubyspec:23F1E (diff:test-all)
>
> 20101011T060001Z is the time chkdbuild runs from; the link is for  
> the result.
> ruby 1.9.3dev (2010-10-11 trunk 29438) [x64-freebsd8.1] is `ruby -v`.
> (fbsd81) is the name of this CI.
> 2730W is the number of warnings of the result.
> 1F0E1S is the result of test-all; 1 Fail 0 Error 1 Skip.
> rubyspec:23F1E is the result of test-rubyspec; 23 Failure 1 Error.
> (diff:test-all) is the link to the diff between this result and the  
> previous result.
>
> Anyway, summary.html is too big; I recommend to see recent.html.
>
> We should keep 0F0E, but in current situation on the environment
> 1F0E46S rubyspec:1F1E is the best result.
> If it is increased, it means someone breaks something.
>
> -- 
> NARUSE, Yui  <naruse@airemix.jp>
>

[ruby-core:37602] Re: CI?

[Ondřej Bílka]

I am not sure how will valgrind play with GC
On Tue, Jun 28, 2011 at 12:05:07PM +0900, Clifford Heath wrote:
> I see quite a few segfault bugs being reported.
> 
> Does anyone use Purify, valgrind, or any such tools?
> I've used Purify extensively in the past, and regard it
> as an essential tool for any C or C++ development.
> Such tools should be *mandatory* for any widely-used
> code-bases.
> 
> Memory corruption bugs are often innocuous, causing
> no effects until a slight change, that can be years after,
> causes random and unrelated crashes to appear
> seemingly out of the blue. Even just re-linking with an
> updated C library, adding a function that affects memory
> layout (so a bug in *another* function shows up), and
> basically the tiniest changes, can trigger a fault to show
> itself.
> 
> The only way to effectively prevent such bugs is a tool
> like Purify, which isolates the source of a potential
> error, possibly long before the subsequent crash.
> Purify is much better than valgrind, by the way. It rewrites
> your object code (including all system shared libraries)
> such that every memory reference is checked; no bounds
> overflows, no read-before-set errors, etc. An incredible and
> under-utilised tool...
> 
> Clifford Heath.
> 
> On 28/06/2011, at 7:45 AM, NARUSE, Yui wrote:
> 
> >(2011/06/28 6:28), Ryan Davis wrote:
> >>Is this an official CI for ruby?
> >
> >It is mine.
> >It is the result of chkbuild on FreeBSD 8.2 x86_64.
> >chkbuild is a CI by akr.
> >http://cvs.m17n.org/viewcvs/ruby/chkbuild/
> >
> >
> >>http://59.106.172.211/~chkbuild/ruby-trunk/summary.html
> >>
> >>If so... how does one read this?? I can't make sense of it.
> >
> >For examle,
> >20101011T060001Z ruby 1.9.3dev (2010-10-11 trunk 29438) [x64-
> >freebsd8.1] (fbsd81) 2730W 1F0E1S rubyspec:23F1E (diff:test-all)
> >
> >20101011T060001Z is the time chkdbuild runs from; the link is for
> >the result.
> >ruby 1.9.3dev (2010-10-11 trunk 29438) [x64-freebsd8.1] is `ruby -v`.
> >(fbsd81) is the name of this CI.
> >2730W is the number of warnings of the result.
> >1F0E1S is the result of test-all; 1 Fail 0 Error 1 Skip.
> >rubyspec:23F1E is the result of test-rubyspec; 23 Failure 1 Error.
> >(diff:test-all) is the link to the diff between this result and
> >the previous result.
> >
> >Anyway, summary.html is too big; I recommend to see recent.html.
> >
> >We should keep 0F0E, but in current situation on the environment
> >1F0E46S rubyspec:1F1E is the best result.
> >If it is increased, it means someone breaks something.
> >
> >-- 
> >NARUSE, Yui  <naruse@airemix.jp>
> >
> 

-- 

Power company testing new voltage spike (creation) equipment

[ruby-core:37611] Re: CI?

[NARUSE, Yui]

2011/6/28 Clifford Heath <clifford.heath@gmail.com>:
> I see quite a few segfault bugs being reported.
>
> Does anyone use Purify, valgrind, or any such tools?
> I've used Purify extensively in the past, and regard it
> as an essential tool for any C or C++ development.
> Such tools should be *mandatory* for any widely-used
> code-bases.

I and some committers use valgrind, or some tools.

> Memory corruption bugs are often innocuous, causing
> no effects until a slight change, that can be years after,
> causes random and unrelated crashes to appear
> seemingly out of the blue. Even just re-linking with an
> updated C library, adding a function that affects memory
> layout (so a bug in *another* function shows up), and
> basically the tiniest changes, can trigger a fault to show
> itself.
>
> The only way to effectively prevent such bugs is a tool
> like Purify, which isolates the source of a potential
> error, possibly long before the subsequent crash.
> Purify is much better than valgrind, by the way. It rewrites
> your object code (including all system shared libraries)
> such that every memory reference is checked; no bounds
> overflows, no read-before-set errors, etc. An incredible and
> under-utilised tool...

If IBM gives us Purify, we may use it.

-- 
NARUSE, Yui  <naruse@airemix.jp>

[ruby-core:37618] Re: CI?

[Clifford Heath]

On 28/06/2011, at 3:04 PM, NARUSE, Yui wrote:
> If IBM gives us Purify, we may use it.

It's worth asking them. In addition, there may be individuals
with their own licenses, or who can use a workplace license.

It's obviously better if it can be used all the time, but even a
single pass over a CI run would find many problems that
have been hiding for years, I'm willing to bet.

Clifford Heath.

[ruby-core:37637] Re: CI?

[Yusuke ENDOH]

Hello,

2011/6/28 Clifford Heath <clifford.heath@gmail.com>:
> On 28/06/2011, at 3:04 PM, NARUSE, Yui wrote:
>>
>> If IBM gives us Purify, we may use it.
>
> It's worth asking them. In addition, there may be individuals
> with their own licenses, or who can use a workplace license.

We have no connections.  Could you please coordinate it?
Contribution for OSS includes not only programming work, but also
such coordinating work, providing machine, employing developers, etc.


> It's obviously better if it can be used all the time, but even a
> single pass over a CI run would find many problems that
> have been hiding for years, I'm willing to bet.

FYI, Coverity provides us the result of their analyis tool, namely
Prevent:

  http://scan.coverity.com/

It is really helpful.

-- 
Yusuke Endoh <mame@tsg.ne.jp>