You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2009/01/27 17:57:53 UTC
Segfault in ruby tests
Joe, Kou,
The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
[[[
hwright@orac:~/dev/svn-trunk$ make check-swig-rb
cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
/usr/bin/ruby -I /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb \
--verbose=normal
Loaded suite .
Started
.................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
[BUG] Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
/bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
--verbose=normal
make: *** [check-swig-rb] Error 134
hwright@orac:~/dev/svn-trunk$
]]]
This is, of course, a blocker for branching 1.6.x.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1059701
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Thu, Feb 5, 2009 at 7:41 PM, Joe Swatosh <jo...@gmail.com> wrote:
> On Thu, Feb 5, 2009 at 1:52 PM, Joe Swatosh <jo...@gmail.com> wrote:
>> On Sat, Jan 31, 2009 at 12:45 AM, Kouhei Sutou <ko...@cozmixng.org> wrote:
>>> Hi,
>>>
>>> In <49...@mail.utexas.edu>
>>> "Segfault in ruby tests" on Tue, 27 Jan 2009 11:57:53 -0600,
>>> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>>>
>>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>>>
>>> I don't know about the detail of the problem but this patch
>>> will solve the problem:
>>>
>
>
>>>
>>
>> In the spirit of kou's patch, but in the bindings area:
>>
>> Index: subversion/bindings/swig/svn_delta.i
>> ===================================================================
>> --- subversion/bindings/swig/svn_delta.i (revision 35664)
>> +++ subversion/bindings/swig/svn_delta.i (working copy)
>> @@ -232,8 +232,10 @@
>> void **handler_baton,
>> apr_pool_t *pool)
>> {
>> + apr_pool_t *sub_pool = sub_pool = svn_pool_create(pool);
>> svn_txdelta_apply(source, target, result_digest, error_info,
>> pool, handler, handler_baton);
>> + svn_pool_destroy(sub_pool);
>> }
>>
>> static svn_error_t *
>>
>
> Doh! Of course I meant:
>
> Index: subversion/bindings/swig/svn_delta.i
> ===================================================================
> --- subversion/bindings/swig/svn_delta.i (revision 35665)
> +++ subversion/bindings/swig/svn_delta.i (working copy)
> @@ -232,8 +232,10 @@
> void **handler_baton,
> apr_pool_t *pool)
> {
> + apr_pool_t *sub_pool = sub_pool = svn_pool_create(pool);
> svn_txdelta_apply(source, target, result_digest, error_info,
> - pool, handler, handler_baton);
> + sub_pool, handler, handler_baton);
> + svn_pool_destroy(sub_pool);
> }
>
> static svn_error_t *
>
Never mind, now that I can build again, this causes a segfault locally.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1110621
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Thu, Feb 5, 2009 at 1:52 PM, Joe Swatosh <jo...@gmail.com> wrote:
> On Sat, Jan 31, 2009 at 12:45 AM, Kouhei Sutou <ko...@cozmixng.org> wrote:
>> Hi,
>>
>> In <49...@mail.utexas.edu>
>> "Segfault in ruby tests" on Tue, 27 Jan 2009 11:57:53 -0600,
>> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>>
>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>>
>> I don't know about the detail of the problem but this patch
>> will solve the problem:
>>
>>
>
> In the spirit of kou's patch, but in the bindings area:
>
> Index: subversion/bindings/swig/svn_delta.i
> ===================================================================
> --- subversion/bindings/swig/svn_delta.i (revision 35664)
> +++ subversion/bindings/swig/svn_delta.i (working copy)
> @@ -232,8 +232,10 @@
> void **handler_baton,
> apr_pool_t *pool)
> {
> + apr_pool_t *sub_pool = sub_pool = svn_pool_create(pool);
> svn_txdelta_apply(source, target, result_digest, error_info,
> pool, handler, handler_baton);
> + svn_pool_destroy(sub_pool);
> }
>
> static svn_error_t *
>
Doh! Of course I meant:
Index: subversion/bindings/swig/svn_delta.i
===================================================================
--- subversion/bindings/swig/svn_delta.i (revision 35665)
+++ subversion/bindings/swig/svn_delta.i (working copy)
@@ -232,8 +232,10 @@
void **handler_baton,
apr_pool_t *pool)
{
+ apr_pool_t *sub_pool = sub_pool = svn_pool_create(pool);
svn_txdelta_apply(source, target, result_digest, error_info,
- pool, handler, handler_baton);
+ sub_pool, handler, handler_baton);
+ svn_pool_destroy(sub_pool);
}
static svn_error_t *
--
Joe
>
> Disclaimer: since I'm not reproducing the error, I'm not sure it will work.
>
> Looking around a little in libsvn_delta, it seems to me that the
> subpool created in svn_txdelta_apply that isn't destroyed there should
> have a comment explaining why? Or if the subpool was destroyed, does
> that help with the segfault? Or maybe I just don't know what I'm
> talking about :-)
>
> --
> Joe
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1110381
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Sat, Jan 31, 2009 at 12:45 AM, Kouhei Sutou <ko...@cozmixng.org> wrote:
> Hi,
>
> In <49...@mail.utexas.edu>
> "Segfault in ruby tests" on Tue, 27 Jan 2009 11:57:53 -0600,
> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>
>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>
> I don't know about the detail of the problem but this patch
> will solve the problem:
>
> Index: subversion/libsvn_delta/text_delta.c
> ===================================================================
> --- subversion/libsvn_delta/text_delta.c (revision 35611)
> +++ subversion/libsvn_delta/text_delta.c (working copy)
> @@ -788,8 +788,11 @@
> apr_pool_t *pool)
> {
> svn_txdelta_stream_t *txstream;
> + apr_pool_t *sub_pool;
> svn_error_t *err;
>
> + sub_pool = svn_pool_create(pool);
> +
> /* ### this is a hack. we should simply read from the stream, construct
> ### some windows, and pass those to the handler. there isn't any reason
> ### to crank up a full "diff" algorithm just to copy a stream.
> @@ -798,8 +801,8 @@
>
> /* Create a delta stream which converts an *empty* bytestream into the
> target bytestream. */
> - svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
> - err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
> + svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
> + err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
>
> if (digest && (! err))
> {
> @@ -809,6 +812,8 @@
> memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
> }
>
> + svn_pool_destroy(sub_pool);
> +
> return err;
> }
>
>
In the spirit of kou's patch, but in the bindings area:
Index: subversion/bindings/swig/svn_delta.i
===================================================================
--- subversion/bindings/swig/svn_delta.i (revision 35664)
+++ subversion/bindings/swig/svn_delta.i (working copy)
@@ -232,8 +232,10 @@
void **handler_baton,
apr_pool_t *pool)
{
+ apr_pool_t *sub_pool = sub_pool = svn_pool_create(pool);
svn_txdelta_apply(source, target, result_digest, error_info,
pool, handler, handler_baton);
+ svn_pool_destroy(sub_pool);
}
static svn_error_t *
Disclaimer: since I'm not reproducing the error, I'm not sure it will work.
Looking around a little in libsvn_delta, it seems to me that the
subpool created in svn_txdelta_apply that isn't destroyed there should
have a comment explaining why? Or if the subpool was destroyed, does
that help with the segfault? Or maybe I just don't know what I'm
talking about :-)
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1109238
Re: Segfault in ruby tests
Posted by Julian Foad <ju...@btopenworld.com>.
Kouhei Sutou wrote:
> In <49...@mail.utexas.edu>
> "Segfault in ruby tests" on Tue, 27 Jan 2009 11:57:53 -0600,
> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>
> > The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>
> I don't know about the detail of the problem but this patch
> will solve the problem:
>
> Index: subversion/libsvn_delta/text_delta.c
> ===================================================================
> --- subversion/libsvn_delta/text_delta.c (revision 35611)
> +++ subversion/libsvn_delta/text_delta.c (working copy)
> @@ -788,8 +788,11 @@
> apr_pool_t *pool)
> {
> svn_txdelta_stream_t *txstream;
> + apr_pool_t *sub_pool;
> svn_error_t *err;
>
> + sub_pool = svn_pool_create(pool);
> +
> /* ### this is a hack. we should simply read from the stream, construct
> ### some windows, and pass those to the handler. there isn't any reason
> ### to crank up a full "diff" algorithm just to copy a stream.
> @@ -798,8 +801,8 @@
>
> /* Create a delta stream which converts an *empty* bytestream into the
> target bytestream. */
> - svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
> - err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
> + svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
> + err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
>
> if (digest && (! err))
> {
> @@ -809,6 +812,8 @@
> memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
> }
>
> + svn_pool_destroy(sub_pool);
> +
> return err;
> }
I believe you're saying that this change makes the problem go away for
you but there is no logical reason why it should. (I can't see any
reason why it should help.) If that's the case, I just want to make sure
that is clear so that nobody will commit this change until we know why
it makes the problem go away.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1091237
Re: Segfault in ruby tests
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <49...@mail.utexas.edu>
"Segfault in ruby tests" on Tue, 27 Jan 2009 11:57:53 -0600,
"Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
I don't know about the detail of the problem but this patch
will solve the problem:
Index: subversion/libsvn_delta/text_delta.c
===================================================================
--- subversion/libsvn_delta/text_delta.c (revision 35611)
+++ subversion/libsvn_delta/text_delta.c (working copy)
@@ -788,8 +788,11 @@
apr_pool_t *pool)
{
svn_txdelta_stream_t *txstream;
+ apr_pool_t *sub_pool;
svn_error_t *err;
+ sub_pool = svn_pool_create(pool);
+
/* ### this is a hack. we should simply read from the stream, construct
### some windows, and pass those to the handler. there isn't any reason
### to crank up a full "diff" algorithm just to copy a stream.
@@ -798,8 +801,8 @@
/* Create a delta stream which converts an *empty* bytestream into the
target bytestream. */
- svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
- err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
+ svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
+ err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
if (digest && (! err))
{
@@ -809,6 +812,8 @@
memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
}
+ svn_pool_destroy(sub_pool);
+
return err;
}
P.S.: I'm still busy... It will be continued at least a few
months... Please expect my response...
Thanks,
--
kou
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1079028
Re: Segfault in ruby tests
Posted by Julian Foad <ju...@btopenworld.com>.
Kouhei Sutou wrote:
> "C. Michael Pilato" <cm...@collab.net> wrote:
>
> > wouldn't expect this to actually remedy a pool lifetime problem. So, if we
> > can't explain exactly why your patch helps and what problem it solves, my
> > vote is -1 on applying it. We don't want to make the tests stop failing; we
> > want to make Subversion work correctly (and we'll happily accept passing
> > tests as a benefit of that change).
>
> I think that "someone says the fix is not correct" or "you
> say the tests are wrong" is needed before you vote -1.
I would say that if any change has no explanation for why it should
work, and appears to be able to "fix" only the symptom and not the
problem, that is sufficient grounds to say it is wrong and to veto it.
> I'm sorry but I don't have time to look into the problem
> now. There are a code that reproduces the problem and a
> patch that fixes (or hides) the problem. It seems that
> someone can look into the problem.
It's OK that you don't have time to look into it now.
> (My expectation WITHOUT foundation: I think that
> svn_txdelta_send_stream() destroys passed pool
> somewhere. The passed pool is not top-level pool
> (svn_pool_create(parent_pool)) normally but it may be
> top-level pool (svn_pool_create(NULL)) in the Ruby bindings
> test. The difference may cause the problem.)
I had a quick look in libsvn_delta and couldn't find the problem. I
noticed the pool usage in libsvn_delta is far from straightforward, so I
couldn't follow it to know whether it is correct.
A pool-lifetime comment like this, and more, would be useful:
[[[
Index: subversion/include/svn_delta.h
===================================================================
--- subversion/include/svn_delta.h (revision 35773)
+++ subversion/include/svn_delta.h (working copy)
@@ -410,10 +410,11 @@
/** Prepare to apply a text delta. @a source is a readable generic stream
* yielding the source data, @a target is a writable generic stream to
* write target data to, and allocation takes place in a sub-pool of
* @a pool. On return, @a *handler is set to a window handler function and
* @a *handler_baton is set to the value to pass as the @a baton argument to
+ * @a *handler. @a pool must survive through all subsequent calls to
* @a *handler.
*
* If @a result_digest is non-NULL, it points to APR_MD5_DIGESTSIZE bytes
* of storage, and the final call to @a handler populates it with the
* MD5 digest of the resulting fulltext.
]]]
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1130689
Re: Segfault in ruby tests
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <49...@collab.net>
"Re: Segfault in ruby tests" on Mon, 09 Feb 2009 09:28:44 -0500,
"C. Michael Pilato" <cm...@collab.net> wrote:
> wouldn't expect this to actually remedy a pool lifetime problem. So, if we
> can't explain exactly why your patch helps and what problem it solves, my
> vote is -1 on applying it. We don't want to make the tests stop failing; we
> want to make Subversion work correctly (and we'll happily accept passing
> tests as a benefit of that change).
I think that "someone says the fix is not correct" or "you
say the tests are wrong" is needed before you vote -1.
I'm sorry but I don't have time to look into the problem
now. There are a code that reproduces the problem and a
patch that fixes (or hides) the problem. It seems that
someone can look into the problem.
(My expectation WITHOUT foundation: I think that
svn_txdelta_send_stream() destroys passed pool
somewhere. The passed pool is not top-level pool
(svn_pool_create(parent_pool)) normally but it may be
top-level pool (svn_pool_create(NULL)) in the Ruby bindings
test. The difference may cause the problem.)
Thanks,
--
kou
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129450
Re: Segfault in ruby tests
Posted by "C. Michael Pilato" <cm...@collab.net>.
Kouhei Sutou wrote:
> I got the same backtrace and my patch fixed the problem on
> my environment. Could you try it if you didn't try it yet?
>
> (I don't know that the patch can be still applied into
> trunk. sorry.)
>
> Index: subversion/libsvn_delta/text_delta.c
> ===================================================================
> --- svn/subversion/libsvn_delta/text_delta.c (revision 35611)
> +++ svn/subversion/libsvn_delta/text_delta.c (working copy)
> @@ -788,8 +788,11 @@
> apr_pool_t *pool)
> {
> svn_txdelta_stream_t *txstream;
> + apr_pool_t *sub_pool;
> svn_error_t *err;
>
> + sub_pool = svn_pool_create(pool);
> +
> /* ### this is a hack. we should simply read from the stream, construct
> ### some windows, and pass those to the handler. there isn't any reason
> ### to crank up a full "diff" algorithm just to copy a stream.
> @@ -798,8 +801,8 @@
>
> /* Create a delta stream which converts an *empty* bytestream into the
> target bytestream. */
> - svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
> - err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
> + svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
> + err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
>
> if (digest && (! err))
> {
> @@ -809,6 +812,8 @@
> memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
> }
>
> + svn_pool_destroy(sub_pool);
> +
> return err;
> }
Do you (or does anyone else) know *why* the patch works, though? I ask
because I'm concerned that we're looking at a memory-related issue that
shows up only for some folks because of the way the bits land on their
machines, and that isn't *fixed* by your patch so much as masked simply
because the code path changes a little and a different pool is used.
Your patch create a subpool of pool and uses it everywhere pool was used,
then destroys the subpool. The lifetime of your subpool is certainly
shorter than the lifetime of pool except when an error happens, so I
wouldn't expect this to actually remedy a pool lifetime problem. So, if we
can't explain exactly why your patch helps and what problem it solves, my
vote is -1 on applying it. We don't want to make the tests stop failing; we
want to make Subversion work correctly (and we'll happily accept passing
tests as a benefit of that change).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129263
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Kouhei Sutou wrote:
> Hi,
>
> In <49...@mail.utexas.edu>
> "Re: Segfault in ruby tests" on Mon, 09 Feb 2009 07:39:23 -0600,
> "Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
>
>> Hyrum K. Wright wrote:
>>> Joe, Kou,
>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>>>
>>> [[[
>>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>>> /usr/bin/ruby -I /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb \
>>> --verbose=normal
>>> Loaded suite .
>>> Started
>>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>>> [BUG] Segmentation fault
>>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>>
>>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>> --verbose=normal
>>> make: *** [check-swig-rb] Error 134
>>> hwright@orac:~/dev/svn-trunk$
>>> ]]]
>>>
>>> This is, of course, a blocker for branching 1.6.x.
>> I finally managed to get a debug version of the ruby libraries installed, which
>> yielded this backtrace:
>>
>> test_apply(SvnDeltaTest):
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread 0x7f3b836296e0 (LWP 20657)]
>> 0x00007f3b825536b0 in strlen () from /lib/libc.so.6
>> (gdb) backtrace#0 0x00007f3b825536b0 in strlen () from /lib/libc.so.6#1
>> 0x00007f3b831c21ce in rb_str_new2 (
>> ptr=0x7b81f0e0 <Address 0x7b81f0e0 out of bounds>) at string.c:115
>> #2 0x00007f3b7d5c0c2e in _wrap_svn_txdelta_send_stream (
>> argc=<value optimized out>, argv=<value optimized out>,
>> self=<value optimized out>) at subversion/bindings/swig/ruby/svn_delta.c:3650
>
> I got the same backtrace and my patch fixed the problem on
> my environment. Could you try it if you didn't try it yet?
>
> (I don't know that the patch can be still applied into
> trunk. sorry.)
>
> Index: subversion/libsvn_delta/text_delta.c
> ===================================================================
> --- svn/subversion/libsvn_delta/text_delta.c (revision 35611)
> +++ svn/subversion/libsvn_delta/text_delta.c (working copy)
> @@ -788,8 +788,11 @@
> apr_pool_t *pool)
> {
> svn_txdelta_stream_t *txstream;
> + apr_pool_t *sub_pool;
> svn_error_t *err;
>
> + sub_pool = svn_pool_create(pool);
> +
> /* ### this is a hack. we should simply read from the stream, construct
> ### some windows, and pass those to the handler. there isn't any reason
> ### to crank up a full "diff" algorithm just to copy a stream.
> @@ -798,8 +801,8 @@
>
> /* Create a delta stream which converts an *empty* bytestream into the
> target bytestream. */
> - svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
> - err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
> + svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
> + err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
>
> if (digest && (! err))
> {
> @@ -809,6 +812,8 @@
> memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
> }
>
> + svn_pool_destroy(sub_pool);
> +
> return err;
> }
>
I applied this patch locally, and it does indeed "fix" the test (for the
definition of fix noted by C-Mike elsethread). Both 'make check-swig-rb' and
'make check' pass.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129356
Re: Segfault in ruby tests
Posted by Kouhei Sutou <ko...@cozmixng.org>.
Hi,
In <49...@mail.utexas.edu>
"Re: Segfault in ruby tests" on Mon, 09 Feb 2009 07:39:23 -0600,
"Hyrum K. Wright" <hy...@mail.utexas.edu> wrote:
> Hyrum K. Wright wrote:
> > Joe, Kou,
> > The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
> >
> > [[[
> > hwright@orac:~/dev/svn-trunk$ make check-swig-rb
> > cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
> > /usr/bin/ruby -I /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb \
> > --verbose=normal
> > Loaded suite .
> > Started
> > .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> > [BUG] Segmentation fault
> > ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
> >
> > /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> > --verbose=normal
> > make: *** [check-swig-rb] Error 134
> > hwright@orac:~/dev/svn-trunk$
> > ]]]
> >
> > This is, of course, a blocker for branching 1.6.x.
>
> I finally managed to get a debug version of the ruby libraries installed, which
> yielded this backtrace:
>
> test_apply(SvnDeltaTest):
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7f3b836296e0 (LWP 20657)]
> 0x00007f3b825536b0 in strlen () from /lib/libc.so.6
> (gdb) backtrace#0 0x00007f3b825536b0 in strlen () from /lib/libc.so.6#1
> 0x00007f3b831c21ce in rb_str_new2 (
> ptr=0x7b81f0e0 <Address 0x7b81f0e0 out of bounds>) at string.c:115
> #2 0x00007f3b7d5c0c2e in _wrap_svn_txdelta_send_stream (
> argc=<value optimized out>, argv=<value optimized out>,
> self=<value optimized out>) at subversion/bindings/swig/ruby/svn_delta.c:3650
I got the same backtrace and my patch fixed the problem on
my environment. Could you try it if you didn't try it yet?
(I don't know that the patch can be still applied into
trunk. sorry.)
Index: subversion/libsvn_delta/text_delta.c
===================================================================
--- svn/subversion/libsvn_delta/text_delta.c (revision 35611)
+++ svn/subversion/libsvn_delta/text_delta.c (working copy)
@@ -788,8 +788,11 @@
apr_pool_t *pool)
{
svn_txdelta_stream_t *txstream;
+ apr_pool_t *sub_pool;
svn_error_t *err;
+ sub_pool = svn_pool_create(pool);
+
/* ### this is a hack. we should simply read from the stream, construct
### some windows, and pass those to the handler. there isn't any reason
### to crank up a full "diff" algorithm just to copy a stream.
@@ -798,8 +801,8 @@
/* Create a delta stream which converts an *empty* bytestream into the
target bytestream. */
- svn_txdelta(&txstream, svn_stream_empty(pool), stream, pool);
- err = svn_txdelta_send_txstream(txstream, handler, handler_baton, pool);
+ svn_txdelta(&txstream, svn_stream_empty(sub_pool), stream, sub_pool);
+ err = svn_txdelta_send_txstream(txstream, handler, handler_baton, sub_pool);
if (digest && (! err))
{
@@ -809,6 +812,8 @@
memcpy(digest, result_md5, APR_MD5_DIGESTSIZE);
}
+ svn_pool_destroy(sub_pool);
+
return err;
}
Thanks,
--
kou
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129230
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Hyrum K. Wright wrote:
> Joe, Kou,
> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>
> [[[
> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
> /usr/bin/ruby -I /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb \
> --verbose=normal
> Loaded suite .
> Started
> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> [BUG] Segmentation fault
> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> --verbose=normal
> make: *** [check-swig-rb] Error 134
> hwright@orac:~/dev/svn-trunk$
> ]]]
>
> This is, of course, a blocker for branching 1.6.x.
I finally managed to get a debug version of the ruby libraries installed, which
yielded this backtrace:
test_apply(SvnDeltaTest):
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f3b836296e0 (LWP 20657)]
0x00007f3b825536b0 in strlen () from /lib/libc.so.6
(gdb) backtrace#0 0x00007f3b825536b0 in strlen () from /lib/libc.so.6#1
0x00007f3b831c21ce in rb_str_new2 (
ptr=0x7b81f0e0 <Address 0x7b81f0e0 out of bounds>) at string.c:115
#2 0x00007f3b7d5c0c2e in _wrap_svn_txdelta_send_stream (
argc=<value optimized out>, argv=<value optimized out>,
self=<value optimized out>) at subversion/bindings/swig/ruby/svn_delta.c:3650
#3 0x00007f3b8315ec40 in rb_call0 (klass=139893488074720, recv=139893488078240,
id=47169, oid=47169, argc=3, argv=0x7fff8b621da0, body=0x7f3b7da9b0b8,
flags=<value optimized out>) at eval.c:5904
#4 0x00007f3b8315edfa in rb_call (klass=139893488074720, recv=139893488078240,
mid=47169, argc=3, argv=0x7fff8b621da0, scope=0, self=139893488060480)
at eval.c:6151
#5 0x00007f3b83158cf0 in rb_eval (self=139893488060480, n=<value optimized out>)
at eval.c:3492
#6 0x00007f3b83169914 in block_pass (self=139893488060480, node=0x7f3b7da7a390)
at eval.c:9138
#7 0x00007f3b8315a830 in rb_eval (self=139893488060480, n=<value optimized out>)
at eval.c:3208
#8 0x00007f3b8315eb43 in rb_call0 (klass=139893488043440, recv=139893488060480,
id=45985, oid=45985, argc=3, argv=0x7fff8b623bc0, body=0x7f3b7da7a4a8,
flags=<value optimized out>) at eval.c:6055
#9 0x00007f3b8315edfa in rb_call (klass=139893488043440, recv=139893488060480,
mid=45985, argc=3, argv=0x7fff8b623bc0, scope=0, self=139893476150240)
at eval.c:6151
#10 0x00007f3b83158cf0 in rb_eval (self=139893476150240, n=<value optimized out>)
at eval.c:3492
#11 0x00007f3b8315eb43 in rb_call0 (klass=139893488077400, recv=139893476150240,
id=4225, oid=4225, argc=0, argv=0x7fff8b624b30, body=0x7f3b7dab4b80,
flags=<value optimized out>) at eval.c:6055
#12 0x00007f3b8315edfa in rb_call (klass=139893488077400, recv=139893476150240,
mid=4225, argc=1, argv=0x7fff8b624b30, scope=0, self=139893475698120)
at eval.c:6151
#13 0x00007f3b83158cf0 in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3492
#14 0x00007f3b8315eb43 in rb_call0 (klass=139893475820160, recv=139893475698120,
id=63729, oid=63729, argc=0, argv=0x7fff8b626138, body=0x7f3b7cf0bef0,
flags=<value optimized out>) at eval.c:6055
#15 0x00007f3b8315edfa in rb_call (klass=139893475820160, recv=139893475698120,
mid=63729, argc=0, argv=0x7fff8b626138, scope=1, self=6) at eval.c:6151
#16 0x00007f3b8315f649 in rb_f_send (argc=1, argv=0x7fff8b626130,
recv=139893475698120) at eval.c:6199
#17 0x00007f3b8315ec40 in rb_call0 (klass=139893584070960, recv=139893475698120,
id=4073, oid=4073, argc=1, argv=0x7fff8b626130, body=0x7f3b83624358,
flags=<value optimized out>) at eval.c:5904
#18 0x00007f3b8315edfa in rb_call (klass=139893584070960, recv=139893475698120,
mid=4073, argc=1, argv=0x7fff8b626130, scope=1, self=139893475698120)
at eval.c:6151
#19 0x00007f3b83158e22 in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3507
#20 0x00007f3b8315be1e in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3308
#21 0x00007f3b8315bfce in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3356
#22 0x00007f3b8315eb43 in rb_call0 (klass=139893583708840, recv=139893475698120,
id=17489, oid=5393, argc=0, argv=0x7fff8b6283a0, body=0x7f3b835fba20,
flags=<value optimized out>) at eval.c:6055
#23 0x00007f3b8315edfa in rb_call (klass=139893583708840, recv=139893475698120,
mid=17489, argc=1, argv=0x7fff8b6283a0, scope=1, self=139893475698120)
---Type <return> to continue, or q <return> to quit---
at eval.c:6151
#24 0x00007f3b83158e22 in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3507
#25 0x00007f3b83169914 in block_pass (self=139893475698120, node=0x7f3b822be3b8)
at eval.c:9138
#26 0x00007f3b8315a830 in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3208
#27 0x00007f3b8315bfce in rb_eval (self=139893475698120, n=<value optimized out>)
at eval.c:3356
#28 0x00007f3b8315eb43 in rb_call0 (klass=139893583708840, recv=139893475698120,
id=5393, oid=5393, argc=0, argv=0x7fff8b62ab30, body=0x7f3b822be480,
flags=<value optimized out>) at eval.c:6055
#29 0x00007f3b8315edfa in rb_call (klass=139893583708840, recv=139893475698120,
mid=5393, argc=1, argv=0x7fff8b62ab30, scope=0, self=139893475699200)
at eval.c:6151
#30 0x00007f3b83158cf0 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3492
#31 0x00007f3b83169914 in block_pass (self=139893475699200, node=0x7f3b835d2a30)
at eval.c:9138
#32 0x00007f3b8315a830 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3208
#33 0x00007f3b8315cf0b in rb_yield_0 (val=139893475698120, self=139893475699200,
klass=0, flags=<value optimized out>, avalue=0) at eval.c:5077
#34 0x00007f3b8313aeb1 in rb_ary_each (ary=139893475698280) at array.c:1261
#35 0x00007f3b8315ec40 in rb_call0 (klass=139893584006200, recv=139893475698280,
id=4001, oid=4001, argc=0, argv=0x0, body=0x7f3b836183f0,
flags=<value optimized out>) at eval.c:5904
#36 0x00007f3b8315edfa in rb_call (klass=139893584006200, recv=139893475698280,
mid=4001, argc=0, argv=0x0, scope=0, self=139893475699200) at eval.c:6151
#37 0x00007f3b83158cf0 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3492
#38 0x00007f3b8315c4d0 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3222
#39 0x00007f3b8315eb43 in rb_call0 (klass=139893583711360, recv=139893475699200,
id=17489, oid=5393, argc=0, argv=0x7fff8b62eac0, body=0x7f3b835d2d28,
flags=<value optimized out>) at eval.c:6055
#40 0x00007f3b8315edfa in rb_call (klass=139893583711360, recv=139893475699200,
mid=17489, argc=1, argv=0x7fff8b62eac0, scope=1, self=139893475699200)
at eval.c:6151
#41 0x00007f3b83158e22 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3507
#42 0x00007f3b83169914 in block_pass (self=139893475699200, node=0x7f3b822bbde8)
at eval.c:9138
#43 0x00007f3b8315a830 in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3208
#44 0x00007f3b8315bfce in rb_eval (self=139893475699200, n=<value optimized out>)
at eval.c:3356
#45 0x00007f3b8315eb43 in rb_call0 (klass=139893583711360, recv=139893475699200,
id=5393, oid=5393, argc=1, argv=0x7fff8b631250, body=0x7f3b822bc1a8,
flags=<value optimized out>) at eval.c:6055
#46 0x00007f3b8315edfa in rb_call (klass=139893583711360, recv=139893475699200,
mid=5393, argc=1, argv=0x7fff8b631250, scope=0, self=139893475099920)
at eval.c:6151
#47 0x00007f3b83158cf0 in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3492
#48 0x00007f3b83169914 in block_pass (self=139893475099920, node=0x7f3b835d2a30)
at eval.c:9138
#49 0x00007f3b8315a830 in rb_eval (self=139893475099920, n=<value optimized out>)
---Type <return> to continue, or q <return> to quit---
at eval.c:3208
#50 0x00007f3b8315cf0b in rb_yield_0 (val=139893475699200, self=139893475099920,
klass=0, flags=<value optimized out>, avalue=0) at eval.c:5077
#51 0x00007f3b8313aeb1 in rb_ary_each (ary=139893475112960) at array.c:1261
#52 0x00007f3b8315ec40 in rb_call0 (klass=139893584006200, recv=139893475112960,
id=4001, oid=4001, argc=0, argv=0x0, body=0x7f3b836183f0,
flags=<value optimized out>) at eval.c:5904
#53 0x00007f3b8315edfa in rb_call (klass=139893584006200, recv=139893475112960,
mid=4001, argc=0, argv=0x0, scope=0, self=139893475099920) at eval.c:6151
#54 0x00007f3b83158cf0 in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3492
#55 0x00007f3b8315c4d0 in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3222
#56 0x00007f3b8315eb43 in rb_call0 (klass=139893583711360, recv=139893475099920,
id=17489, oid=5393, argc=0, argv=0x7fff8b6351e0, body=0x7f3b835d2d28,
flags=<value optimized out>) at eval.c:6055
#57 0x00007f3b8315edfa in rb_call (klass=139893583711360, recv=139893475099920,
mid=17489, argc=1, argv=0x7fff8b6351e0, scope=1, self=139893475099920)
at eval.c:6151
#58 0x00007f3b83158e22 in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3507
#59 0x00007f3b83169914 in block_pass (self=139893475099920, node=0x7f3b822bbde8)
at eval.c:9138
#60 0x00007f3b8315a830 in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3208
#61 0x00007f3b8315bfce in rb_eval (self=139893475099920, n=<value optimized out>)
at eval.c:3356
#62 0x00007f3b8315eb43 in rb_call0 (klass=139893583711360, recv=139893475099920,
id=5393, oid=5393, argc=1, argv=0x7fff8b637970, body=0x7f3b822bc1a8,
flags=<value optimized out>) at eval.c:6055
#63 0x00007f3b8315edfa in rb_call (klass=139893583711360, recv=139893475099920,
mid=5393, argc=1, argv=0x7fff8b637970, scope=0, self=139893474599640)
at eval.c:6151
#64 0x00007f3b83158cf0 in rb_eval (self=139893474599640, n=<value optimized out>)
at eval.c:3492
#65 0x00007f3b8315c4d0 in rb_eval (self=139893474599640, n=<value optimized out>)
at eval.c:3222
#66 0x00007f3b8315eb43 in rb_call0 (klass=139893563732960, recv=139893474599640,
id=17025, oid=17033, argc=0, argv=0x0, body=0x7f3b835d4588,
flags=<value optimized out>) at eval.c:6055
#67 0x00007f3b8315edfa in rb_call (klass=139893563732960, recv=139893474599640,
mid=17025, argc=0, argv=0x0, scope=2, self=139893474599640) at eval.c:6151
#68 0x00007f3b83158e68 in rb_eval (self=139893474599640, n=<value optimized out>)
at eval.c:3513
#69 0x00007f3b8315be1e in rb_eval (self=139893474599640, n=<value optimized out>)
at eval.c:3308
#70 0x00007f3b8315eb43 in rb_call0 (klass=139893563732960, recv=139893474599640,
id=17033, oid=17033, argc=0, argv=0x0, body=0x7f3b835ddbd8,
flags=<value optimized out>) at eval.c:6055
#71 0x00007f3b8315edfa in rb_call (klass=139893563732960, recv=139893474599640,
mid=17033, argc=0, argv=0x0, scope=0, self=139893474601440) at eval.c:6151
#72 0x00007f3b83158cf0 in rb_eval (self=139893474601440, n=<value optimized out>)
at eval.c:3492
#73 0x00007f3b83159094 in rb_eval (self=139893474601440, n=<value optimized out>)
at eval.c:3436
#74 0x00007f3b8315eb43 in rb_call0 (klass=139893474601120, recv=139893474601440,
id=66953, oid=66953, argc=0, argv=0x0, body=0x7f3b7cdc65b8,
flags=<value optimized out>) at eval.c:6055
---Type <return> to continue, or q <return> to quit---
#75 0x00007f3b8315edfa in rb_call (klass=139893474601120, recv=139893474601440,
mid=66953, argc=0, argv=0x0, scope=2, self=139893474601440) at eval.c:6151
#76 0x00007f3b83158e68 in rb_eval (self=139893474601440, n=<value optimized out>)
at eval.c:3513
#77 0x00007f3b83159094 in rb_eval (self=139893474601440, n=<value optimized out>)
at eval.c:3436
#78 0x00007f3b8315eb43 in rb_call0 (klass=139893474601120, recv=139893474601440,
id=5313, oid=5313, argc=0, argv=0x0, body=0x7f3b7cdc7fd0,
flags=<value optimized out>) at eval.c:6055
#79 0x00007f3b8315edfa in rb_call (klass=139893474601120, recv=139893474601440,
mid=5313, argc=0, argv=0x0, scope=0, self=139893474601120) at eval.c:6151
#80 0x00007f3b83158cf0 in rb_eval (self=139893474601120, n=<value optimized out>)
at eval.c:3492
#81 0x00007f3b83159094 in rb_eval (self=139893474601120, n=<value optimized out>)
at eval.c:3436
#82 0x00007f3b8315eb43 in rb_call0 (klass=139893474600920, recv=139893474601120,
id=5393, oid=5393, argc=0, argv=0x7fff8b63f5a0, body=0x7f3b835c0510,
flags=<value optimized out>) at eval.c:6055
#83 0x00007f3b8315edfa in rb_call (klass=139893474600920, recv=139893474601120,
mid=5393, argc=2, argv=0x7fff8b63f5a0, scope=0, self=139893487291840)
at eval.c:6151
#84 0x00007f3b83158cf0 in rb_eval (self=139893487291840, n=<value optimized out>)
at eval.c:3492
#85 0x00007f3b83158c0e in rb_eval (self=139893487291840, n=<value optimized out>)
at eval.c:3486
#86 0x00007f3b8315eb43 in rb_call0 (klass=139893583306240, recv=139893487291840,
id=5393, oid=5393, argc=0, argv=0x0, body=0x7f3b835c1c08,
flags=<value optimized out>) at eval.c:6055
#87 0x00007f3b8315edfa in rb_call (klass=139893583306240, recv=139893487291840,
mid=5393, argc=0, argv=0x0, scope=0, self=139893583306240) at eval.c:6151
#88 0x00007f3b83158cf0 in rb_eval (self=139893583306240, n=<value optimized out>)
at eval.c:3492
#89 0x00007f3b8315eb43 in rb_call0 (klass=139893583306200, recv=139893583306240,
id=5393, oid=5393, argc=0, argv=0x7fff8b641e20, body=0x7f3b835cf1c8,
flags=<value optimized out>) at eval.c:6055
#90 0x00007f3b8315edfa in rb_call (klass=139893583306200, recv=139893583306240,
mid=5393, argc=2, argv=0x7fff8b641e20, scope=0, self=139893584061080)
at eval.c:6151
#91 0x00007f3b83158cf0 in rb_eval (self=139893584061080, n=<value optimized out>)
at eval.c:3492
#92 0x00007f3b8315b803 in rb_eval (self=139893584061080, n=<value optimized out>)
at eval.c:3502
#93 0x00007f3b8316bdbb in ruby_exec_internal () at eval.c:1641
#94 0x00007f3b8316be05 in ruby_exec () at eval.c:1661
#95 0x00007f3b8316be32 in ruby_run () at eval.c:1671
#96 0x00000000004008e3 in main (argc=5, argv=0x7fff8b643818,
envp=<value optimized out>) at main.c:48
(gdb)
Hope that helps!
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1129100
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Thu, Jan 29, 2009 at 10:27 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe Swatosh wrote:
>> <hy...@mail.utexas.edu> wrote:
>>>> On Wed, Jan 28, 2009 at 10:36 AM, Hyrum K. Wright
>>>> <hy...@mail.utexas.edu> wrote:
>>>>> Joe Swatosh wrote:
>>>>>> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
>>>>>> <hy...@mail.utexas.edu> wrote:
>>>>>>> Joe, Kou,
>>>>>>> The ruby bindings tests are segfaulting on the buildbot. I can
>>>>>>> reproduce
>>>>>>> locally:
>>> the buildbot continued to fail.
>>>
>>
>> I'm not much help. Maybe try running the tests with a -v so we will
>> at least know the name of the test that causes the segfault?
>
> hwright@orac:~/dev/svn-trunk/subversion/bindings/swig/ruby$ /usr/bin/ruby -I
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> -v
> Loaded suite .
> Started
> ...
> test_apply(SvnDeltaTest):
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> [BUG] Segmentation fault
> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
Not much to go on. Looking back at the buildbot results r35373 was
the last time the x64-ubuntu gcc passed. So:
D:\SVN\src-trunk>svn log -rhead:35373 subversion\libsvn_delta
------------------------------------------------------------------------
D:\SVN\src-trunk>
Really nothing to go on.
D:\SVN\src-trunk>svn log -rhead:35373 subversion\include\svn_delta.h
------------------------------------------------------------------------
r35424 | gstein | 2009-01-23 10:30:04 -0800 (Fri, 23 Jan 2009) | 86 lines
Adjust a bunch of our public header files:
- make sure everything the header needs is included
- make sure nothing is included which is NOT needed
Added an exception to svn_types.h: it now explicitly includes svn_error.h
since Everybody needs that thing. We go ahead and make it easy for them,
even though that is counter-philosophy.
After altering the header files, some .c files in our codebase would not
compile -- they used stuff that they did not explicitly include. Thus, a
goodly number of .c files were updated, too.
* subversion/libsvn_ra/wrapper_template.h:
* subversion/libsvn_ra/deprecated.c:
* subversion/libsvn_ra/compat.c:
* subversion/libsvn_subr/iter.c:
* subversion/libsvn_subr/cmdline.c:
* subversion/libsvn_subr/ssl_client_cert_pw_providers.c:
* subversion/libsvn_subr/error.c:
* subversion/libsvn_subr/auth.c:
* subversion/libsvn_subr/opt.c:
* subversion/libsvn_subr/checksum.c:
* subversion/libsvn_subr/compat.c:
* subversion/libsvn_subr/sha1.c:
* subversion/libsvn_subr/deprecated.c:
* subversion/libsvn_subr/ssl_server_trust_providers.c:
* subversion/mod_dav_svn/activity.c:
* subversion/mod_dav_svn/reports/log.c:
* subversion/tests/libsvn_fs/fs-test.c:
* subversion/tests/libsvn_repos/repos-test.c:
* subversion/svn/list-cmd.c:
* subversion/svn/changelist-cmd.c:
* subversion/svn/log-cmd.c:
* subversion/svn/conflict-callbacks.c:
* subversion/libsvn_fs_base/dag.c:
* subversion/libsvn_fs_base/util/fs_skels.c:
* subversion/include/svn_dirent_uri.h:
* subversion/include/svn_error_codes.h:
* subversion/include/svn_fs.h:
* subversion/include/svn_diff.h:
* subversion/include/svn_sorts.h:
* subversion/include/svn_mergeinfo.h:
* subversion/include/svn_base64.h:
* subversion/include/svn_dso.h:
* subversion/include/svn_ra_svn.h:
* subversion/include/svn_repos.h:
* subversion/include/svn_delta.h:
* subversion/include/svn_path.h:
* subversion/include/svn_subst.h:
* subversion/include/svn_xml.h:
* subversion/include/svn_props.h:
* subversion/include/svn_iter.h:
* subversion/include/svn_types.h:
* subversion/include/svn_config.h:
* subversion/include/svn_string.h:
* subversion/include/svn_io.h:
* subversion/include/svn_wc.h:
* subversion/include/svn_cmdline.h:
* subversion/include/svn_client.h:
* subversion/include/svn_user.h:
* subversion/include/svn_hash.h:
* subversion/include/svn_md5.h:
* subversion/include/svn_error.h:
* subversion/include/svn_pools.h:
* subversion/include/private/svn_log.h:
* subversion/include/svn_time.h:
* subversion/include/svn_utf.h:
* subversion/include/svn_auth.h:
* subversion/include/svn_ra.h:
* subversion/include/svn_opt.h:
* subversion/include/svn_checksum.h:
* subversion/libsvn_wc/deprecated.c:
* subversion/libsvn_wc/util.c:
* subversion/libsvn_wc/merge.c:
* subversion/libsvn_wc/tree_conflicts.c:
* subversion/libsvn_client/list.c:
* subversion/libsvn_client/log.c:
* subversion/libsvn_ra_neon/util.c:
* subversion/libsvn_ra_neon/log.c:
* subversion/libsvn_repos/deprecated.c:
* subversion/libsvn_fs_fs/tree.c:
* subversion/libsvn_fs_fs/fs_fs.c:
(): adjust #include statements appropriately
------------------------------------------------------------------------
D:\SVN\src-trunk>
Okay that seems really unlikely....
> The buildbot is back up, too, so you can see the error in the binding test
> output.
What do you see at:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=552&dsMessageId=1069466
? :-)
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1072192
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Tue, Feb 24, 2009 at 2:34 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
>
>
> The only place I see this particular failure is the buildbot. I can't even
> reproduce it locally on the same box, using the same setup as the buildbot.
> I've applied the patch locally, but get the same no-failure result as I do
> without the patch. Funny business indeed.
>
> That being said, if you think this patch improve the state of the world, I
> see no reason it shouldn't be committed.
>
And
On Sat, Feb 21, 2009 at 9:06 AM, David James <ja...@gmail.com> wrote:
>
>
> I haven't tested the patch, but it looks good in theory. One comment
> (see below):
>
> I don't think the variable "temp" is needed here anymore. This comment
> also applies to the Python version (I added this unused variable
> accidentally in r21423).
Good point.
> Anyway, if the test suite passes with your change, I say it is a good
> idea to commit it, because it fixes a known memory corruption bug.
>
r36171
Thanks for reviewing.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1236923
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Feb 27, 7:03 am, "Hyrum K. Wright" <hy...@mail.utexas.edu>
wrote:
> On Feb 27, 2009, at 12:14 AM, Joe Swatosh wrote:
>
>
>
>
>
> > On Tue, Feb 24, 2009 at 2:34 PM, Hyrum K. Wright
> > <hy...@mail.utexas.edu> wrote:
>
> >> Also, there are currently *two* binding failures on the buildbot,
> >> one of
> >> which is the mystery failure, and another which is quite
> >> reproducible:
>
> >> Started
> >> ..............................................................E
> >> ............................................................................................................................................................
> >> Finished in 525.856881 seconds.
>
> >> 1) Error:
> >> test_status_with_depth(SvnClientTest):
> >> Svn::Error::WcNotLocked:
> >> subversion/libsvn_wc/lock.c:910: Svn::Error::WcNotLocked: Unable to
> >> lock
> >> 'wc-tmp/wc/A/B'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
> >> util.rb:86:in
> >> `svn_client_status3'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
> >> util.rb:86:in
> >> `status3'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
> >> client.rb:176:in
> >> `status'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
> >> test_client.rb:469:in
> >> `test_status_with_depth'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
> >> test_client.rb:468:in
> >> `each'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
> >> test_client.rb:468:in
> >> `test_status_with_depth'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
> >> util.rb:181:in
> >> `make_context'
> >> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
> >> test_client.rb:463:in
> >> `test_status_with_depth'
>
> > I noticed this one in the buildbot results, too. I'm not getting it
> > locally,
> > but I will look into it a bit as time is available.
>
> > Is it possible to have the buildbot results show up in the message
> > to the
> > list? I hate to whine, but it is at least two clicks to figure out
> > what actually
> > caused the failure. Doesn't sound like much, but it feels slooow.
>
> I actually thought there was a list one could subscribe to to get the
> buildbot results (svn-breakage maybe?) I don't see it doc'd on the
> website, though.
>
> -Hyrum
I'm subscribed to the breakage list. The message just says the
build failed and has a link. No details of the actual failure. When
I follow the link, I have to then follow another link to figure out
what
actually failed. It is not insurmounatable, just inconvenient.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1239607
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Feb 27, 2009, at 12:14 AM, Joe Swatosh wrote:
> On Tue, Feb 24, 2009 at 2:34 PM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>
>>
>> Also, there are currently *two* binding failures on the buildbot,
>> one of
>> which is the mystery failure, and another which is quite
>> reproducible:
>>
>> Started
>> ..............................................................E
>> ............................................................................................................................................................
>> Finished in 525.856881 seconds.
>>
>> 1) Error:
>> test_status_with_depth(SvnClientTest):
>> Svn::Error::WcNotLocked:
>> subversion/libsvn_wc/lock.c:910: Svn::Error::WcNotLocked: Unable to
>> lock
>> 'wc-tmp/wc/A/B'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
>> util.rb:86:in
>> `svn_client_status3'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
>> util.rb:86:in
>> `status3'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
>> client.rb:176:in
>> `status'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
>> test_client.rb:469:in
>> `test_status_with_depth'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
>> test_client.rb:468:in
>> `each'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
>> test_client.rb:468:in
>> `test_status_with_depth'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
>> util.rb:181:in
>> `make_context'
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
>> test_client.rb:463:in
>> `test_status_with_depth'
>>
>
> I noticed this one in the buildbot results, too. I'm not getting it
> locally,
> but I will look into it a bit as time is available.
>
> Is it possible to have the buildbot results show up in the message
> to the
> list? I hate to whine, but it is at least two clicks to figure out
> what actually
> caused the failure. Doesn't sound like much, but it feels slooow.
I actually thought there was a list one could subscribe to to get the
buildbot results (svn-breakage maybe?) I don't see it doc'd on the
website, though.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1239294
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Tue, Feb 24, 2009 at 2:34 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
>
> Also, there are currently *two* binding failures on the buildbot, one of
> which is the mystery failure, and another which is quite reproducible:
>
> Started
> ..............................................................E............................................................................................................................................................
> Finished in 525.856881 seconds.
>
> 1) Error:
> test_status_with_depth(SvnClientTest):
> Svn::Error::WcNotLocked:
> subversion/libsvn_wc/lock.c:910: Svn::Error::WcNotLocked: Unable to lock
> 'wc-tmp/wc/A/B'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> `svn_client_status3'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:in
> `status3'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/client.rb:176:in
> `status'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/test_client.rb:469:in
> `test_status_with_depth'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/test_client.rb:468:in
> `each'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/test_client.rb:468:in
> `test_status_with_depth'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/util.rb:181:in
> `make_context'
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/test_client.rb:463:in
> `test_status_with_depth'
>
I noticed this one in the buildbot results, too. I'm not getting it locally,
but I will look into it a bit as time is available.
Is it possible to have the buildbot results show up in the message to the
list? I hate to whine, but it is at least two clicks to figure out
what actually
caused the failure. Doesn't sound like much, but it feels slooow.
Thanks
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1236941
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Feb 18, 2009, at 3:39 PM, Joe Swatosh wrote:
> On Wed, Feb 18, 2009 at 12:41 PM, Joe Swatosh
> <jo...@gmail.com> wrote:
>> On Wed, Feb 18, 2009 at 12:35 PM, Joe Swatosh
>> <jo...@gmail.com> wrote:
>>
>>
>>>
>>> I have 3 ideas:
>>>
>>> 1) Follow the precedent of the Python bindings and just remove the
>>> digest.
>
> Delete bad ideas 2 and 3....
>
>>>
>>> I'm thinking 1 is quickest and has a precedent. 2 and 3 might be
>>> over my head.
>>>
>>
>
> Hyrum,
>
> This passes locally, but of course it was passing locally without it.
> Could you please give it a try to see if it helps?
The only place I see this particular failure is the buildbot. I can't
even reproduce it locally on the same box, using the same setup as the
buildbot. I've applied the patch locally, but get the same no-failure
result as I do without the patch. Funny business indeed.
That being said, if you think this patch improve the state of the
world, I see no reason it shouldn't be committed.
Also, there are currently *two* binding failures on the buildbot, one
of which is the mystery failure, and another which is quite
reproducible:
Started
..............................................................E
............................................................................................................................................................
Finished in 525.856881 seconds.
1) Error:
test_status_with_depth(SvnClientTest):
Svn::Error::WcNotLocked:
subversion/libsvn_wc/lock.c:910: Svn::Error::WcNotLocked: Unable to
lock 'wc-tmp/wc/A/B'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:
86:in `svn_client_status3'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:
86:in `status3'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/
client.rb:176:in `status'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
test_client.rb:469:in `test_status_with_depth'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
test_client.rb:468:in `each'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
test_client.rb:468:in `test_status_with_depth'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/util.rb:
181:in `make_context'
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/
test_client.rb:463:in `test_status_with_depth'
> [[[
>
> Fix failing Ruby bindings test in the spirit of the fix for Python
> in r21423:
> "Fix segfault in Python tests by deleting the broken argout typemap
> for the
> 'result_digest' parameter in svn_txdelta_apply. Instead, ignore the
> parameter
> altogether."
>
> * subversion/bindings/swig/include/svn_types.swg
> (result_digest): Remove typemap for Ruby. Instead, ignore
> the parameter.
>
> * subversion/bindings/swig/ruby/svn/delta.rb
> (Svn::Delta.apply): Don't expect a digest to be returned by
> Svn::Delta.txdelta_apply_wrapper and don't return it.
>
> * subversion/bindings/swig/ruby/test/test_delta.rb
> (SvnDeltaTest#test_apply): Don't expect a digest returned with the
> handler
> from Svn::Delta.apply.
>
> ]]]
>
>
> Index: subversion/bindings/swig/ruby/test/test_delta.rb
> ===================================================================
> --- subversion/bindings/swig/ruby/test/test_delta.rb (revision 35962)
> +++ subversion/bindings/swig/ruby/test/test_delta.rb (working copy)
> @@ -125,17 +125,17 @@
> apply_source = StringIO.new(source_text)
> apply_result = StringIO.new("")
>
> - handler, digest = Svn::Delta.apply(apply_source, apply_result)
> + handler = Svn::Delta.apply(apply_source, apply_result)
> handler.send(stream)
> apply_result.rewind
> assert_equal(target_text, apply_result.read)
>
> - handler, digest = Svn::Delta.apply(apply_source, apply_result)
> + handler = Svn::Delta.apply(apply_source, apply_result)
> handler.send(target_text)
> apply_result.rewind
> assert_equal(target_text * 2, apply_result.read)
>
> - handler, digest = Svn::Delta.apply(apply_source, apply_result)
> + handler = Svn::Delta.apply(apply_source, apply_result)
> handler.send(StringIO.new(target_text))
> apply_result.rewind
> assert_equal(target_text * 3, apply_result.read)
> Index: subversion/bindings/swig/ruby/svn/delta.rb
> ===================================================================
> --- subversion/bindings/swig/ruby/svn/delta.rb (revision 35962)
> +++ subversion/bindings/swig/ruby/svn/delta.rb (working copy)
> @@ -52,9 +52,9 @@
>
> def apply(source, target, error_info=nil)
> result = Delta.txdelta_apply_wrapper(source, target, error_info)
> - digest, handler, handler_baton = result
> + handler, handler_baton = result
> handler.baton = handler_baton
> - [handler, digest]
> + handler
> end
>
> def parse_svndiff(error_on_early_close=true, &handler)
> Index: subversion/bindings/swig/include/svn_types.swg
> ===================================================================
> --- subversion/bindings/swig/include/svn_types.swg (revision 35962)
> +++ subversion/bindings/swig/include/svn_types.swg (working copy)
> @@ -1060,11 +1060,12 @@
> %apply unsigned char digest[ANY] { unsigned char *digest };
>
> #ifdef SWIGRUBY
> -/* FIXME: This typemap doesn't work, because svn_txdelta_apply saves
> - * away this local pointer to be used later. When the pointer
> - * is finally used, we get memory corruption / segfaults.
> +/*
> + * Skip the md5sum
> + * FIXME: Wrap the md5sum
> */
> -%apply unsigned char digest[ANY] { unsigned char *result_digest };
> +%typemap(in, numinputs=0) unsigned char *result_digest
> + ($*1_type temp[APR_MD5_DIGESTSIZE]) "$1 = NULL;";
> #endif
>
> #ifdef SWIGPYTHON
> <ruby-segfault.patch>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1223031
Re: Segfault in ruby tests
Posted by David James <ja...@gmail.com>.
On Wed, Feb 18, 2009 at 1:39 PM, Joe Swatosh <jo...@gmail.com> wrote:
>>>
>>> I'm thinking 1 is quickest and has a precedent. 2 and 3 might be over my head.
>>>
>>
>
> Hyrum,
>
> This passes locally, but of course it was passing locally without it.
> Could you please give it a try to see if it helps?
>
Hi Joe,
I haven't tested the patch, but it looks good in theory. One comment
(see below):
> -/* FIXME: This typemap doesn't work, because svn_txdelta_apply saves
> - * away this local pointer to be used later. When the pointer
> - * is finally used, we get memory corruption / segfaults.
> +/*
> + * Skip the md5sum
> + * FIXME: Wrap the md5sum
> */
> -%apply unsigned char digest[ANY] { unsigned char *result_digest };
> +%typemap(in, numinputs=0) unsigned char *result_digest
> + ($*1_type temp[APR_MD5_DIGESTSIZE]) "$1 = NULL;";
> #endif
I don't think the variable "temp" is needed here anymore. This comment
also applies to the Python version (I added this unused variable
accidentally in r21423).
Anyway, if the test suite passes with your change, I say it is a good
idea to commit it, because it fixes a known memory corruption bug.
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1204000
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Feb 18, 2009 at 12:41 PM, Joe Swatosh <jo...@gmail.com> wrote:
> On Wed, Feb 18, 2009 at 12:35 PM, Joe Swatosh <jo...@gmail.com> wrote:
>
>
>>
>> I have 3 ideas:
>>
>> 1) Follow the precedent of the Python bindings and just remove the digest.
Delete bad ideas 2 and 3....
>>
>> I'm thinking 1 is quickest and has a precedent. 2 and 3 might be over my head.
>>
>
Hyrum,
This passes locally, but of course it was passing locally without it.
Could you please give it a try to see if it helps?
--
Joe
[[[
Fix failing Ruby bindings test in the spirit of the fix for Python in r21423:
"Fix segfault in Python tests by deleting the broken argout typemap for the
'result_digest' parameter in svn_txdelta_apply. Instead, ignore the parameter
altogether."
* subversion/bindings/swig/include/svn_types.swg
(result_digest): Remove typemap for Ruby. Instead, ignore
the parameter.
* subversion/bindings/swig/ruby/svn/delta.rb
(Svn::Delta.apply): Don't expect a digest to be returned by
Svn::Delta.txdelta_apply_wrapper and don't return it.
* subversion/bindings/swig/ruby/test/test_delta.rb
(SvnDeltaTest#test_apply): Don't expect a digest returned with the handler
from Svn::Delta.apply.
]]]
Index: subversion/bindings/swig/ruby/test/test_delta.rb
===================================================================
--- subversion/bindings/swig/ruby/test/test_delta.rb (revision 35962)
+++ subversion/bindings/swig/ruby/test/test_delta.rb (working copy)
@@ -125,17 +125,17 @@
apply_source = StringIO.new(source_text)
apply_result = StringIO.new("")
- handler, digest = Svn::Delta.apply(apply_source, apply_result)
+ handler = Svn::Delta.apply(apply_source, apply_result)
handler.send(stream)
apply_result.rewind
assert_equal(target_text, apply_result.read)
- handler, digest = Svn::Delta.apply(apply_source, apply_result)
+ handler = Svn::Delta.apply(apply_source, apply_result)
handler.send(target_text)
apply_result.rewind
assert_equal(target_text * 2, apply_result.read)
- handler, digest = Svn::Delta.apply(apply_source, apply_result)
+ handler = Svn::Delta.apply(apply_source, apply_result)
handler.send(StringIO.new(target_text))
apply_result.rewind
assert_equal(target_text * 3, apply_result.read)
Index: subversion/bindings/swig/ruby/svn/delta.rb
===================================================================
--- subversion/bindings/swig/ruby/svn/delta.rb (revision 35962)
+++ subversion/bindings/swig/ruby/svn/delta.rb (working copy)
@@ -52,9 +52,9 @@
def apply(source, target, error_info=nil)
result = Delta.txdelta_apply_wrapper(source, target, error_info)
- digest, handler, handler_baton = result
+ handler, handler_baton = result
handler.baton = handler_baton
- [handler, digest]
+ handler
end
def parse_svndiff(error_on_early_close=true, &handler)
Index: subversion/bindings/swig/include/svn_types.swg
===================================================================
--- subversion/bindings/swig/include/svn_types.swg (revision 35962)
+++ subversion/bindings/swig/include/svn_types.swg (working copy)
@@ -1060,11 +1060,12 @@
%apply unsigned char digest[ANY] { unsigned char *digest };
#ifdef SWIGRUBY
-/* FIXME: This typemap doesn't work, because svn_txdelta_apply saves
- * away this local pointer to be used later. When the pointer
- * is finally used, we get memory corruption / segfaults.
+/*
+ * Skip the md5sum
+ * FIXME: Wrap the md5sum
*/
-%apply unsigned char digest[ANY] { unsigned char *result_digest };
+%typemap(in, numinputs=0) unsigned char *result_digest
+ ($*1_type temp[APR_MD5_DIGESTSIZE]) "$1 = NULL;";
#endif
#ifdef SWIGPYTHON
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1188225
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Feb 18, 2009 at 12:35 PM, Joe Swatosh <jo...@gmail.com> wrote:
>
> I have 3 ideas:
>
> 1) Follow the precedent of the Python bindings and just remove the digest.
> 2) Create an appropriately sized buffer in a member variable and pass
> it into Delta.txdelta_apply_wrapper (changing SWIG to use it instead
> of creating one)
> 3) Use kou's idea from the client context, create a pool associated
> with the object and allocate the buffer with that instead of on the
> stack.
>
> I'm thinking 1 is quickest and has a precedent. 2 and 3 might be over my head.
>
Nevermind 2 and 3 apply is a module function not an instance function.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1187974
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Tue, Feb 17, 2009 at 8:27 AM, David James <ja...@gmail.com> wrote:
> On Mon, Feb 16, 2009 at 10:30 PM, Joe Swatosh <jo...@gmail.com> wrote:
>>
>> On Thu, Jan 29, 2009 at 10:27 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>> > Joe Swatosh wrote:
>> >>
>>
>> blah, blah
>>
>> >> I'm not much help. Maybe try running the tests with a -v so we will
>> >> at least know the name of the test that causes the segfault?
>> >
>> > hwright@orac:~/dev/svn-trunk/subversion/bindings/swig/ruby$ /usr/bin/ruby -I
>> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>> > -v
>> > Loaded suite .
>> > Started
>> > ...
>> > test_apply(SvnDeltaTest):
>> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>> > [BUG] Segmentation fault
>> > ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>> >
>> > The buildbot is back up, too, so you can see the error in the binding test
>> > output.
>>
>> Since the tests are failing on the build bot again, I just wanted to
>> put this note out there (I don't know what to do with it yet):
>>
>> [[[
>> D:\SVN\src-trunk>svn log -c21423
>> ------------------------------------------------------------------------
>> r21423 | djames | 2006-09-11 09:48:15 -0700 (Mon, 11 Sep 2006) | 32 lines
>>
>> Fix segfault in Python tests by deleting the broken
>> argout typemap for the 'result_digest' parameter in
>> svn_txdelta_apply. Instead, ignore the parameter
>> altogether.
>>
>> svn_txdelta_apply should not return 'result_digest'
>> as a String, because the result digest is not ready
>> yet when svn.delta.tx_apply is finished. Instead,
>> we should probably allocate a StringIO buffer,
>> so that the user can check the return values as
>> needed.
>>
>> (FIXME: We should define a compatibility policy for
>> the SWIG bindings. svn_txdelta_apply is not the only
>> function whose interface will need to be changed
>> to make it actually work [i.e., not segfault]. If
>> we actually made an "official list" of the tested
>> APIs, with documentation, it would probably be quite
>> useful for both users and developers. I'm +1 on
>> defining any semi-broken APIs, such as this one,
>> as "experimental, and subject to change".)
>>
>>
>> * subversion/bindings/swig/include/svn_types.swg
>> (result_digest): Remove typemap. Instead, ignore
>> the parameter.
>>
>> * subversion/bindings/swig/python/tests/delta.py:
>> Adjust to compensate for removed 'digest'
>> parameter.
>
> Hi Joe,
>
> Thanks for bringing up this history! svn_txdelta_apply has an unusual
> API so it is difficult to wrap.
> Here's more details, which I added in r21423 to a comment in svn_types.swg
>
> 'unsigned char *result_digest'
> This parameter serves as a buffer for the digest results of
> svn_txdelta_apply. As you supply data to this function via
> the handler callback, this digest gets filled. Since
> filling of this buffer is delayed, it is quite difficult
> to wrap.
>
> FIXME: Both Ruby and Perl have broken typemaps for result_digest.
> The Python bindings ignore this parameter altogether.
>
> Looking in svn_types.swg, you can still see my warning about the Ruby
> typemap being broken:
>
> /* FIXME: This typemap doesn't work, because svn_txdelta_apply saves
> * away this local pointer to be used later. When the pointer
> * is finally used, we get memory corruption / segfaults.
> */
> %apply unsigned char digest[ANY] { unsigned char *result_digest };
>
> To be clear, the issue here is that the argument that the argument
> that the Ruby bindings pass in to svn_txdelta_apply has the wrong
> lifetime. svn_txdelta_apply saves the pointer to result_digest away in
> the hander_baton, and expects that this pointer will still be valid
> later when the handler function is invoked. However, the pointer we
> pass in is a pointer to a variable on the stack, and therefore it will
> no longer be valid when svn_txdelta_apply exits.
>
> Fixing this issue properly is a little complex. For the digest
> functionality to work, the caller to svn_txdelta_apply should allocate
> the memory for holding the digest from a pool that lives just as long
> as the delta window handler. Further, the Ruby bindings would need to
> be given a pointer to this memory so that they can access the digest
> after it has been set by the window handler.
>
> In the Python bindings, you can see that I bypassed the problem by
> teaching the bindings to ignore the parameter altogether (see r21423).
> I justified this compatibility break on the basis that the function
> was previously completely broken due to the segfault issue. Hopefully,
> in the future, someone will design a better fix that will allow the
> md5 digest to be accessed.
>
> What do you think the Ruby bindings should do?
>
I have 3 ideas:
1) Follow the precedent of the Python bindings and just remove the digest.
2) Create an appropriately sized buffer in a member variable and pass
it into Delta.txdelta_apply_wrapper (changing SWIG to use it instead
of creating one)
3) Use kou's idea from the client context, create a pool associated
with the object and allocate the buffer with that instead of on the
stack.
I'm thinking 1 is quickest and has a precedent. 2 and 3 might be over my head.
I'll try to produce a patch that Hyrum can try for 1.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1187944
Re: Segfault in ruby tests
Posted by David James <ja...@gmail.com>.
On Mon, Feb 16, 2009 at 10:30 PM, Joe Swatosh <jo...@gmail.com> wrote:
>
> On Thu, Jan 29, 2009 at 10:27 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
> > Joe Swatosh wrote:
> >>
>
> blah, blah
>
> >> I'm not much help. Maybe try running the tests with a -v so we will
> >> at least know the name of the test that causes the segfault?
> >
> > hwright@orac:~/dev/svn-trunk/subversion/bindings/swig/ruby$ /usr/bin/ruby -I
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> > -v
> > Loaded suite .
> > Started
> > ...
> > test_apply(SvnDeltaTest):
> > /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> > [BUG] Segmentation fault
> > ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
> >
> > The buildbot is back up, too, so you can see the error in the binding test
> > output.
>
> Since the tests are failing on the build bot again, I just wanted to
> put this note out there (I don't know what to do with it yet):
>
> [[[
> D:\SVN\src-trunk>svn log -c21423
> ------------------------------------------------------------------------
> r21423 | djames | 2006-09-11 09:48:15 -0700 (Mon, 11 Sep 2006) | 32 lines
>
> Fix segfault in Python tests by deleting the broken
> argout typemap for the 'result_digest' parameter in
> svn_txdelta_apply. Instead, ignore the parameter
> altogether.
>
> svn_txdelta_apply should not return 'result_digest'
> as a String, because the result digest is not ready
> yet when svn.delta.tx_apply is finished. Instead,
> we should probably allocate a StringIO buffer,
> so that the user can check the return values as
> needed.
>
> (FIXME: We should define a compatibility policy for
> the SWIG bindings. svn_txdelta_apply is not the only
> function whose interface will need to be changed
> to make it actually work [i.e., not segfault]. If
> we actually made an "official list" of the tested
> APIs, with documentation, it would probably be quite
> useful for both users and developers. I'm +1 on
> defining any semi-broken APIs, such as this one,
> as "experimental, and subject to change".)
>
>
> * subversion/bindings/swig/include/svn_types.swg
> (result_digest): Remove typemap. Instead, ignore
> the parameter.
>
> * subversion/bindings/swig/python/tests/delta.py:
> Adjust to compensate for removed 'digest'
> parameter.
Hi Joe,
Thanks for bringing up this history! svn_txdelta_apply has an unusual
API so it is difficult to wrap.
Here's more details, which I added in r21423 to a comment in svn_types.swg
'unsigned char *result_digest'
This parameter serves as a buffer for the digest results of
svn_txdelta_apply. As you supply data to this function via
the handler callback, this digest gets filled. Since
filling of this buffer is delayed, it is quite difficult
to wrap.
FIXME: Both Ruby and Perl have broken typemaps for result_digest.
The Python bindings ignore this parameter altogether.
Looking in svn_types.swg, you can still see my warning about the Ruby
typemap being broken:
/* FIXME: This typemap doesn't work, because svn_txdelta_apply saves
* away this local pointer to be used later. When the pointer
* is finally used, we get memory corruption / segfaults.
*/
%apply unsigned char digest[ANY] { unsigned char *result_digest };
To be clear, the issue here is that the argument that the argument
that the Ruby bindings pass in to svn_txdelta_apply has the wrong
lifetime. svn_txdelta_apply saves the pointer to result_digest away in
the hander_baton, and expects that this pointer will still be valid
later when the handler function is invoked. However, the pointer we
pass in is a pointer to a variable on the stack, and therefore it will
no longer be valid when svn_txdelta_apply exits.
Fixing this issue properly is a little complex. For the digest
functionality to work, the caller to svn_txdelta_apply should allocate
the memory for holding the digest from a pool that lives just as long
as the delta window handler. Further, the Ruby bindings would need to
be given a pointer to this memory so that they can access the digest
after it has been set by the window handler.
In the Python bindings, you can see that I bypassed the problem by
teaching the bindings to ignore the parameter altogether (see r21423).
I justified this compatibility break on the basis that the function
was previously completely broken due to the segfault issue. Hopefully,
in the future, someone will design a better fix that will allow the
md5 digest to be accessed.
What do you think the Ruby bindings should do?
Cheers,
David
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1179700
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Thu, Jan 29, 2009 at 10:27 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe Swatosh wrote:
>>
blah, blah
>> I'm not much help. Maybe try running the tests with a -v so we will
>> at least know the name of the test that causes the segfault?
>
> hwright@orac:~/dev/svn-trunk/subversion/bindings/swig/ruby$ /usr/bin/ruby -I
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> -v
> Loaded suite .
> Started
> ...
> test_apply(SvnDeltaTest):
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> [BUG] Segmentation fault
> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
> The buildbot is back up, too, so you can see the error in the binding test
> output.
Since the tests are failing on the build bot again, I just wanted to
put this note out there (I don't know what to do with it yet):
[[[
D:\SVN\src-trunk>svn log -c21423
------------------------------------------------------------------------
r21423 | djames | 2006-09-11 09:48:15 -0700 (Mon, 11 Sep 2006) | 32 lines
Fix segfault in Python tests by deleting the broken
argout typemap for the 'result_digest' parameter in
svn_txdelta_apply. Instead, ignore the parameter
altogether.
svn_txdelta_apply should not return 'result_digest'
as a String, because the result digest is not ready
yet when svn.delta.tx_apply is finished. Instead,
we should probably allocate a StringIO buffer,
so that the user can check the return values as
needed.
(FIXME: We should define a compatibility policy for
the SWIG bindings. svn_txdelta_apply is not the only
function whose interface will need to be changed
to make it actually work [i.e., not segfault]. If
we actually made an "official list" of the tested
APIs, with documentation, it would probably be quite
useful for both users and developers. I'm +1 on
defining any semi-broken APIs, such as this one,
as "experimental, and subject to change".)
* subversion/bindings/swig/include/svn_types.swg
(result_digest): Remove typemap. Instead, ignore
the parameter.
* subversion/bindings/swig/python/tests/delta.py:
Adjust to compensate for removed 'digest'
parameter.
------------------------------------------------------------------------
]]]
Good night.
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1176577
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Joe Swatosh wrote:
> On Wed, Jan 28, 2009 at 3:10 PM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Joe Swatosh wrote:
>>> On Wed, Jan 28, 2009 at 10:36 AM, Hyrum K. Wright
>>> <hy...@mail.utexas.edu> wrote:
>>>> Joe Swatosh wrote:
>>>>> Howdy Hyrum,
>>>>>
>>>>> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
>>>>> <hy...@mail.utexas.edu> wrote:
>>>>>> Joe, Kou,
>>>>>> The ruby bindings tests are segfaulting on the buildbot. I can
>>>>>> reproduce
>>>>>> locally:
>>>>>>
>>>>>> [[[
>>>>>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>>>>>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>>>>>> /usr/bin/ruby -I
>>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>>>>>
>>>>>>
>>>>>>
>>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>>>> \
>>>>>> --verbose=normal
>>>>>> Loaded suite .
>>>>>> Started
>>>>>>
>>>>>>
>>>>>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>>>>>> [BUG] Segmentation fault
>>>>>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>>>>>
>>>>>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>>>>>>
>>>>>>
>>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>>>> --verbose=normal
>>>>>> make: *** [check-swig-rb] Error 134
>>>>>> hwright@orac:~/dev/svn-trunk$
>>>>>> ]]]
>>>>>>
>>>>>> This is, of course, a blocker for branching 1.6.x.
>>>>>>
>>>>> I cannot reproduce at r35519.
>>>> Troubling, I can still reproduce the error. The buildbot should be
>>>> reproducing it, too, but the buildslave appears to be asleep at the
>>>> moment.
>>>>
>>> Any notion of when it started?
>> Unfortnately, no. I just discovered it when the JavaHL tests were fixed but
>> the buildbot continued to fail.
>>
>
> I'm not much help. Maybe try running the tests with a -v so we will
> at least know the name of the test that causes the segfault?
hwright@orac:~/dev/svn-trunk/subversion/bindings/swig/ruby$ /usr/bin/ruby -I
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb -v
Loaded suite .
Started
...
test_apply(SvnDeltaTest):
/home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86: [BUG]
Segmentation fault
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
The buildbot is back up, too, so you can see the error in the binding test output.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1069619
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Jan 28, 2009 at 3:10 PM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe Swatosh wrote:
>>
>> On Wed, Jan 28, 2009 at 10:36 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>>
>>> Joe Swatosh wrote:
>>>>
>>>> Howdy Hyrum,
>>>>
>>>> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
>>>> <hy...@mail.utexas.edu> wrote:
>>>>>
>>>>> Joe, Kou,
>>>>> The ruby bindings tests are segfaulting on the buildbot. I can
>>>>> reproduce
>>>>> locally:
>>>>>
>>>>> [[[
>>>>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>>>>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>>>>> /usr/bin/ruby -I
>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>>>>
>>>>>
>>>>>
>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>>> \
>>>>> --verbose=normal
>>>>> Loaded suite .
>>>>> Started
>>>>>
>>>>>
>>>>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>>>>> [BUG] Segmentation fault
>>>>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>>>>
>>>>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>>>>>
>>>>>
>>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>>> --verbose=normal
>>>>> make: *** [check-swig-rb] Error 134
>>>>> hwright@orac:~/dev/svn-trunk$
>>>>> ]]]
>>>>>
>>>>> This is, of course, a blocker for branching 1.6.x.
>>>>>
>>>> I cannot reproduce at r35519.
>>>
>>> Troubling, I can still reproduce the error. The buildbot should be
>>> reproducing it, too, but the buildslave appears to be asleep at the
>>> moment.
>>>
>>
>> Any notion of when it started?
>
> Unfortnately, no. I just discovered it when the JavaHL tests were fixed but
> the buildbot continued to fail.
>
I'm not much help. Maybe try running the tests with a -v so we will
at least know the name of the test that causes the segfault?
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1069135
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Joe Swatosh wrote:
> On Wed, Jan 28, 2009 at 10:36 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Joe Swatosh wrote:
>>> Howdy Hyrum,
>>>
>>> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
>>> <hy...@mail.utexas.edu> wrote:
>>>> Joe, Kou,
>>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce
>>>> locally:
>>>>
>>>> [[[
>>>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>>>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>>>> /usr/bin/ruby -I
>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>>>
>>>>
>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>> \
>>>> --verbose=normal
>>>> Loaded suite .
>>>> Started
>>>>
>>>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>>>> [BUG] Segmentation fault
>>>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>>>
>>>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>>>>
>>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>>> --verbose=normal
>>>> make: *** [check-swig-rb] Error 134
>>>> hwright@orac:~/dev/svn-trunk$
>>>> ]]]
>>>>
>>>> This is, of course, a blocker for branching 1.6.x.
>>>>
>>> I cannot reproduce at r35519.
>> Troubling, I can still reproduce the error. The buildbot should be
>> reproducing it, too, but the buildslave appears to be asleep at the moment.
>>
>
> Any notion of when it started?
Unfortnately, no. I just discovered it when the JavaHL tests were fixed but the
buildbot continued to fail.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1065212
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
On Wed, Jan 28, 2009 at 10:36 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe Swatosh wrote:
>>
>> Howdy Hyrum,
>>
>> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
>> <hy...@mail.utexas.edu> wrote:
>>>
>>> Joe, Kou,
>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce
>>> locally:
>>>
>>> [[[
>>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>>> /usr/bin/ruby -I
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>>
>>>
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>> \
>>> --verbose=normal
>>> Loaded suite .
>>> Started
>>>
>>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>>> [BUG] Segmentation fault
>>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>>
>>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>>>
>>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>>> --verbose=normal
>>> make: *** [check-swig-rb] Error 134
>>> hwright@orac:~/dev/svn-trunk$
>>> ]]]
>>>
>>> This is, of course, a blocker for branching 1.6.x.
>>>
>>
>> I cannot reproduce at r35519.
>
> Troubling, I can still reproduce the error. The buildbot should be
> reproducing it, too, but the buildslave appears to be asleep at the moment.
>
Any notion of when it started?
--
Joe
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1065010
Re: Segfault in ruby tests
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Joe Swatosh wrote:
> Howdy Hyrum,
>
> On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
> <hy...@mail.utexas.edu> wrote:
>> Joe, Kou,
>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce
>> locally:
>>
>> [[[
>> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
>> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
>> /usr/bin/ruby -I
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>>
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>> \
>> --verbose=normal
>> Loaded suite .
>> Started
>> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
>> [BUG] Segmentation fault
>> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>>
>> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
>> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
>> --verbose=normal
>> make: *** [check-swig-rb] Error 134
>> hwright@orac:~/dev/svn-trunk$
>> ]]]
>>
>> This is, of course, a blocker for branching 1.6.x.
>>
>
> I cannot reproduce at r35519.
Troubling, I can still reproduce the error. The buildbot should be reproducing
it, too, but the buildslave appears to be asleep at the moment.
-Hyrum
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1063930
Re: Segfault in ruby tests
Posted by Joe Swatosh <jo...@gmail.com>.
Howdy Hyrum,
On Tue, Jan 27, 2009 at 9:57 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Joe, Kou,
> The ruby bindings tests are segfaulting on the buildbot. I can reproduce
> locally:
>
> [[[
> hwright@orac:~/dev/svn-trunk$ make check-swig-rb
> cd /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby; \
> /usr/bin/ruby -I
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby \
>
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> \
> --verbose=normal
> Loaded suite .
> Started
> .................................................................................................................../home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/svn/util.rb:86:
> [BUG] Segmentation fault
> ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]
>
> /bin/bash: line 3: 17077 Aborted /usr/bin/ruby -I
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby
> /home/hwright/dev/svn-trunk/subversion/bindings/swig/ruby/test/run-test.rb
> --verbose=normal
> make: *** [check-swig-rb] Error 134
> hwright@orac:~/dev/svn-trunk$
> ]]]
>
> This is, of course, a blocker for branching 1.6.x.
>
I cannot reproduce at r35519.
--
Joe Swatosh
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1061706