#50 √ resolved
Brian Ford

Object#object_id (object_get_id) cause exception

Reported by Brian Ford | October 16th, 2007 @ 01:23 AM | in 1.0 preview

After a certain number of times, accessing #object_id will cause an exception. However, attempting to access it on a new object will succeed a certain number of times and then cause an exception.

sirb(eval):000> 1.upto(100) { |i| a = Array.new; p a.object_id }
262681
262689
--- snip ---
263465
263473
=> 1
sirb(eval):001> 1.upto(100) { |i| a = Array.new; p a.object_id }
Attempted to access field of non reference.

An exception has occurred:
    Attempted to access field of non-reference (null pointer) (ArgumentError)
Backtrace:
       main.__eval_script__ at (eval):1
       Integer(Fixnum)#upto at kernel/core/integer.rb:24
       main.__eval_script__ at (eval):1
    CompiledMethod#activate at kernel/core/compiled_method.rb:110
            main.__script__ at lib/bin/sirb.rb:133
                  main.load at kernel/core/compile.rb:78
               main.require at kernel/core/compile.rb:129
                 Array#each at kernel/core/array.rb:549
      Integer(Fixnum)#times at kernel/core/integer.rb:15
                 Array#each at kernel/core/array.rb:549
               main.require at kernel/core/compile.rb:112
                 Array#each at kernel/core/array.rb:549
      Integer(Fixnum)#times at kernel/core/integer.rb:15
                 Array#each at kernel/core/array.rb:549
               main.require at kernel/core/compile.rb:111
            main.__script__ at kernel/loader.rb:150
sirb(eval):002> Array.new.object_id
=> 264161
sirb(eval):003> 1.upto(100) { |i| a = Array.new; p a.object_id }
Attempted to access field of non reference.

An exception has occurred:
    Attempted to access field of non-reference (null pointer) (ArgumentError)
Backtrace:
       main.__eval_script__ at (eval):1
       Integer(Fixnum)#upto at kernel/core/integer.rb:24
       main.__eval_script__ at (eval):1
    CompiledMethod#activate at kernel/core/compiled_method.rb:110
            main.__script__ at lib/bin/sirb.rb:133
                  main.load at kernel/core/compile.rb:78
               main.require at kernel/core/compile.rb:129
                 Array#each at kernel/core/array.rb:549
      Integer(Fixnum)#times at kernel/core/integer.rb:15
                 Array#each at kernel/core/array.rb:549
               main.require at kernel/core/compile.rb:112
                 Array#each at kernel/core/array.rb:549
      Integer(Fixnum)#times at kernel/core/integer.rb:15
                 Array#each at kernel/core/array.rb:549
               main.require at kernel/core/compile.rb:111
            main.__script__ at kernel/loader.rb:150
sirb(eval):004> 

Comments and changes to this ticket

  • Brian Ford

    Brian Ford October 16th, 2007 @ 01:34 AM

    • → State changed from “new” to “open”

    Recompiling cpu_primitives.c with DEV=1 and setting a breakpoint at machine_handle_fire gives this.

    sirb(eval):001> 1.upto(100) { |i| a = Array.new; p a.object_id }
    Attempted to access field of non reference.
    
    Breakpoint 1, machine_handle_fire (kind=2) at machine.c:460
    460       g_access_violation = kind;
    (gdb) bt
    #0  machine_handle_fire (kind=2) at machine.c:460
    #1  0x00218f80 in _bad_reference (in=14) at state.h:275
    #2  0x0022101f in cpu_run (state=0x8000, ic=0x500770, setup=0) at instruction_dt.gen:727
    #3  0x0024e76d in machine_run (m=0x500180) at machine.c:507
    #4  0x0024e877 in machine_run_file (m=0x500180, path=0x2040 "runtime/loader.rbc") at machine.c:532
    #5  0x00001d81 in main (argc=1, argv=0xbffff978) at main.c:115
    (gdb) rbt
      0x610450 <none>#<block>+41 in (eval):1
      0x610400 Integer#upto+26 in kernel/core/integer.rb:24
      0x6103b0 <none>#__eval_script__+66 in (eval):1
      0x610360 CompiledMethod#activate+71 in kernel/core/compiled_method.rb:110
     0x2105e20 Class#__script__+820 in lib/bin/sirb.rb:113
     0x2106168 Kernel#load+281 in kernel/core/compile.rb:78
     0x2107d44 <none>#<block>+270 in kernel/core/compile.rb:129
     0x210914c <none>#<block>+34 in kernel/core/array.rb:549
     0x210df98 Integer#times+22 in kernel/core/integer.rb:15
     0x2112ae4 Array#each+42 in kernel/core/array.rb:549
     0x210e09c <none>#<block>+403 in kernel/core/compile.rb:112
     0x2112bcc <none>#<block>+34 in kernel/core/array.rb:549
     0x212e0d0 Integer#times+22 in kernel/core/integer.rb:15
     0x2140a94 Array#each+42 in kernel/core/array.rb:549
     0x210e04c Kernel#require+420 in kernel/core/compile.rb:111
     0x2112b4c Class#__script__+1334 in kernel/loader.rb:150
    $1 = void
    (gdb)
    
    
  • Brian Ford

    Brian Ford October 18th, 2007 @ 01:05 PM

    This appears related to blocks because you can do any of the following without causing it:

    sirb(eval):008> i = 0; while i < 100; p Array.new.object_id; i += 1; end
    (repeatedly)
    
    sirb(eval):009> p Array.new.object_id                                   
    272601
    => nil
    sirb(eval):010> p Array.new.object_id
    272777
    => nil
    sirb(eval):011> p Array.new.object_id
    272953
    => nil
    sirb(eval):012> p Array.new.object_id
    273129
    => nil
    (repeatedly)
    
    sirb(eval):013> def out
    sirb(eval):014* p Array.new.object_id
    sirb(eval):015* end
    => #<CompiledMethod:0x42be9 name=out file=(eval)>
    sirb(eval):016> i = 0; while i < 100; out; i += 1; end                  
    (repeatedly)
    
  • Brian Ford

    Brian Ford October 18th, 2007 @ 01:10 PM

    Apparently this is only manifesting in sirb as well.

  • Charles L

    Charles L November 9th, 2007 @ 01:45 AM

    Another thing that only triggers in sirb:

    sirb(eval):000> (1...100).inject { |a, b| a * 4 }
    => 100433627766186892221372630771322662657637687111424552206336
    sirb(eval):001> (1...100).inject { |a, b| a * 4 }
    Attempted to access field of non reference.
    

    Where as:

    % cat test4.rb
    (1...100).inject { |a, b| a * 4 }
    (1...100).inject { |a, b| a * 4 }
    % ./shotgun/rubinius test4.rb
    %
    
  • zimbatm

    zimbatm January 16th, 2008 @ 05:18 AM

    I wasn't able to reproduce the problem on 18470055d83a4...

    Wasn't it related to the return value of the block that wouldn't be accessible ?

  • Brian Ford

    Brian Ford January 20th, 2008 @ 12:52 PM

    • → State changed from “open” to “resolved”

    I don't seem to be able to reproduce it either. Closing this.

  • Charles L

    Charles L January 23rd, 2008 @ 11:10 PM

    No longer able to reproduce also... Hmmm

Please Login or create a free account to add a new comment.

You can update this ticket by sending an email to from your email client. (help)

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket

Tags