[#14696] Inconsistency in rescuability of "return" — Charles Oliver Nutter <charles.nutter@...>

Why can you not rescue return, break, etc when they are within

21 messages 2008/01/02
[#14699] Re: Inconsistency in rescuability of "return" — Gary Wright <gwtmp01@...> 2008/01/02

[#14738] Enumerable#zip Needs Love — James Gray <james@...>

The community has been building a Ruby 1.9 compatibility tip list on

15 messages 2008/01/03
[#14755] Re: Enumerable#zip Needs Love — Martin Duerst <duerst@...> 2008/01/04

Hello James,

[#14772] Manual Memory Management — Pramukta Kumar <prak@...>

I was thinking it would be nice to be able to free large objects at

36 messages 2008/01/04
[#14788] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/05

I would only like to add that RMgick for example provides free method to

[#14824] Re: Manual Memory Management — MenTaLguY <mental@...> 2008/01/07

On Sat, 5 Jan 2008 15:49:30 +0900, Marcin Raczkowski <mailing.mr@gmail.com> wrote:

[#14825] Re: Manual Memory Management — "Evan Weaver" <evan@...> 2008/01/07

Python supports 'del reference', which decrements the reference

[#14838] Re: Manual Memory Management — Marcin Raczkowski <mailing.mr@...> 2008/01/08

Evan Weaver wrote:

[#14911] Draft of some pages about encoding in Ruby 1.9 — Dave Thomas <dave@...>

Folks:

24 messages 2008/01/10

[#14976] nil encoding as synonym for binary encoding — David Flanagan <david@...>

The following just appeared in the ChangeLog

37 messages 2008/01/11
[#14977] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14978] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14979] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Dave Thomas wrote:

[#14993] Re: nil encoding as synonym for binary encoding — Dave Thomas <dave@...> 2008/01/11

[#14980] Re: nil encoding as synonym for binary encoding — Gary Wright <gwtmp01@...> 2008/01/11

[#14981] Re: nil encoding as synonym for binary encoding — Yukihiro Matsumoto <matz@...> 2008/01/11

Hi,

[#14995] Re: nil encoding as synonym for binary encoding — David Flanagan <david@...> 2008/01/11

Yukihiro Matsumoto writes:

[#15050] how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...>

Core Rubies:

17 messages 2008/01/13
[#15060] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 08:54 AM, Phlip wrote:

[#15062] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Phlip <phlip2005@...> 2008/01/14

Eric Hodel wrote:

[#15073] Re: how to "borrow" the RDoc::RubyParser and HTMLGenerator — Eric Hodel <drbrain@...7.net> 2008/01/14

On Jan 13, 2008, at 20:35 PM, Phlip wrote:

[#15185] Friendlier methods to compare two Time objects — "Jim Cropcho" <jim.cropcho@...>

Hello,

10 messages 2008/01/22

[#15194] Can large scale projects be successful implemented around a dynamic programming language? — Jordi <mumismo@...>

A good article I have found (may have been linked by slashdot, don't know)

8 messages 2008/01/24

[#15248] Symbol#empty? ? — "David A. Black" <dblack@...>

Hi --

24 messages 2008/01/28
[#15250] Re: Symbol#empty? ? — Yukihiro Matsumoto <matz@...> 2008/01/28

Hi,

Re: Segmentation fault when calling procs

From: Chris "ク" Heath <chris@...>
Date: 2008-01-11 07:04:08 UTC
List: ruby-core #14983
On Wed, 2008-01-09 at 19:22 +0900, Guy Decoux wrote:
> >>>>> "C" == Chris "ク" Heath <Chris> writes:
> 
> C> http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/14395
> 
>  Can you give a smaller example : this seems too big to try to debug it

After a lot of painful debugging, I got a small example, a patch that
fixes it, and an explanation of what was going wrong.  :-)

Program:

class A
  def get_block
    return proc do
      test()
    end
  end

  def test
    puts "Test"
  end
end

def new_block
  A.new.get_block
end

block = new_block()
block2 = new_block()
GC.start
block.call


Output (for me, anyway):

test.rb:4: [BUG] Segmentation fault
ruby 1.9.0 (2007-12-25 revision 0) [i686-linux]

-- control frame ----------
c:0006 p:0007 s:0013 b:0012 l:000b5c d:000011 BLOCK  test.rb:4
c:0005 p:---- s:0013 b:0013 l:000012 d:000012 FINISH :new
c:0004 p:---- s:0011 b:0011 l:000010 d:000010 CFUNC  :call
c:0003 p:0052 s:0008 b:0008 l:000007 d:000007 TOP    test.rb:20
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH :inherited
c:0001 p:0000 s:0002 b:0002 l:000001 d:000001 TOP    <dummy toplevel>:16
---------------------------
DBG> : "test.rb:20:in `call'"
DBG> : "test.rb:20:in `<main>'"
-- backtrace of native function call (Use addr2line) --
0x80dc014
0x80f4472
0x80f44a4
0x80b173d
0x45aa90
0x80581bf
0x805820d
0x80582da
0x80d8523
0x80d8c75
0x80d938c
0x80d9573
0x805e7d8
0x80d9b9c
0x80d4775
0x80d8c75
0x80da5b6
0x80589d5
0x805b8d0
0x8057f3a
0x2f8de3
0x8057e65
-------------------------------------------------------
Aborted


Patch:

Index: proc.c
===================================================================
--- proc.c      (revision 14959)
+++ proc.c      (working copy)
@@ -53,6 +53,7 @@
        RUBY_MARK_UNLESS_NULL(proc->blockprocval);
        RUBY_MARK_UNLESS_NULL((VALUE)proc->special_cref_stack);
        RUBY_MARK_UNLESS_NULL(proc->block.proc);
+       RUBY_MARK_UNLESS_NULL(proc->block.self);
        if (proc->block.iseq && RUBY_VM_IFUNC_P(proc->block.iseq)) {
            RUBY_MARK_UNLESS_NULL((VALUE)(proc->block.iseq));
        }


Explanation: 

The garbage collector was freeing the object A.new, even though a proc
still existed with self = A.new.

When you call the proc (block.call), it enters the proc fine, but it
fails to call test() because its "self" is corrupted.

The block2 = new_block() appears to be irrelevant at first sight, but
its function is to remove all traces of A.new from the machine stack,
otherwise the garbage collector still sees it.

I also discovered some machine stack memory leaks (which will be the
subject of a new thread), which had the side-effect of leaving traces of
A.new on the stack, making this crash even harder to reproduce.  I found
the best way to work around the stack leaks was to put the
A.new.get_block calls inside a method.

Chris


In This Thread