[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Segfault in ruby tests

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 09 Feb 2009 08:50:47 -0600

Kouhei Sutou wrote:
> Hi,
>
> In <4990320B.1070408_at_mail.utexas.edu>
> "Re: Segfault in ruby tests" on Mon, 09 Feb 2009 07:39:23 -0600,
> "Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu> wrote:
>
>> Hyrum K. Wright wrote:
>>> Joe, Kou,
>>> The ruby bindings tests are segfaulting on the buildbot. I can reproduce locally:
>>>
>>> [[[
>>> hwright_at_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_at_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
Received on 2009-02-09 16:00:19 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.