June 2011 - macruby-tickets - lists.macosforge.org

[MacRuby] #1331: memory leak occurs when calculate binary-tree.
by MacRuby 17 Jun '11

17 Jun '11

#1331: memory leak occurs when calculate binary-tree. ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- I will atach a test script.[[BR]] when I calculate binary-tree, MacRuby latest needs huge memory. MacRuby 0.10 did not. {{{ $ macruby0.10 -v bm_binary_trees.rb MacRuby 0.10 (ruby 1.9.2) [universal-darwin10.0, x86_64] 19460 KB $ macruby -v bm_binary_trees.rb MacRuby 0.11 (ruby 1.9.2) [universal-darwin10.4, x86_64] 1812296 KB }}} MacRuby 0.10 = 19.4 MB[[BR]] MacRuby 0.11 = 1.8 GB I got a original script from https://github.com/acangiano/ruby-benchmark- suite/blob/master/benchmarks/micro-benchmarks/bm_binary_trees.rb -- Ticket URL: <http://www.macruby.org/trac/ticket/1331> MacRuby <http://macruby.org/>

1 6

[MacRuby] #1330: GCD freezes when sync is called from within async > 10000 times
by MacRuby 16 Jun '11

16 Jun '11

#1330: GCD freezes when sync is called from within async > 10000 times -----------------------------------------+---------------------------------- Reporter: niko.schwarz@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -----------------------------------------+---------------------------------- The following code snippet freezes for the loop being executed 10000 times (0 % cpu usage and doesn't finish), but finishes for 1000 times. It should never freeze. #!/usr/bin/env macruby -w @unzipQueue = Dispatch::Queue.new('ch.unibe.niko.unzipQueue') def extractFile(n) @unzipQueue.sync do end end group = Dispatch::Group.new (1..10000).each { | project | Dispatch::Queue.concurrent.async(group) do extractFile(project) end } group.wait I'm not aware of a workable workaround. -- Ticket URL: <http://www.macruby.org/trac/ticket/1330> MacRuby <http://macruby.org/>

1 0

[MacRuby] #1292: slows down method dispatch at "git commit 68ac3fcaf1041ef9b25fb3bc940a47f41505b7e5"
by MacRuby 16 Jun '11

16 Jun '11

#1292: slows down method dispatch at "git commit 68ac3fcaf1041ef9b25fb3bc940a47f41505b7e5" ------------------------------+--------------------------------------------- Reporter: kouji@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.11 Component: MacRuby | Keywords: ------------------------------+--------------------------------------------- From Laurent: i also see that the VM outer variable is set during dispatch, with retain/release this is not good, because it slows down method dispatch significantly. {{{ $ time /System/Library/PrivateFrameworks/MacRuby.framework/Versions/Current/usr/bin/macruby -e "def foo;42;end; i=0; while i<1000000; foo; foo; foo; foo; foo; i+=1; end" real 0m0.355s user 0m0.339s sys 0m0.011s $ time ./miniruby -e "def foo;42;end; i=0; while i<1000000; foo; foo; foo; foo; foo; i+=1; end"push_outer:3165:push_outer outer_stack(NSObject) real 0m1.155s user 0m1.095s sys 0m0.017s }}} the first is an "old" version of macruby (before the recent const lookup changes) we cannot keep that, so we need to find out a better way, i'm afraid -- Ticket URL: <http://www.macruby.org/trac/ticket/1292> MacRuby <http://macruby.org/>

1 5

[MacRuby] #1285: Constants missing error when the constants are declared in the class definition
by MacRuby 16 Jun '11

16 Jun '11

#1285: Constants missing error when the constants are declared in the class definition ----------------------------+----------------------------------------------- Reporter: tglee@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------+----------------------------------------------- At "git commit 68ac3fcaf1041ef9b25fb3bc940a47f41505b7e5" When one class is defined in an object-C type and another a ruby class in which constants are declared in the inner class definition, build process is OK but constants missing error is shown in runtime at Xcode 4. When the constants are defined in the outer ruby class definition, all processes are well done. -- Ticket URL: <http://www.macruby.org/trac/ticket/1285> MacRuby <http://macruby.org/>

1 9

[MacRuby] #1321: ObjcC/C++ exception thrown but not caught on NoMethodError
by MacRuby 16 Jun '11

16 Jun '11

#1321: ObjcC/C++ exception thrown but not caught on NoMethodError ------------------------------------+--------------------------------------- Reporter: mrada@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: reduction ------------------------------------+--------------------------------------- {{{ framework 'Cocoa' NSDictionary.alloc.initWithKeysAndObjects(1,2,nil) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/1321> MacRuby <http://macruby.org/>

1 1

[MacRuby] #1325: Segfault occurs with Matrix#inv
by MacRuby 15 Jun '11

15 Jun '11

#1325: Segfault occurs with Matrix#inv ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Test Script: {{{ #!ruby require 'mathn' def matrix(dimension) rows = Array.new (1..dimension).each do |i| row = Array.new (1..dimension).each do |j| row.push(1/(i + j - 1)) end rows.push(row) end return(Matrix.rows(rows)) end m = matrix(30) m.inv }}} BackTrace: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010 0x00007fff84f2b11c in objc_msgSend () (gdb) bt 20 #0 0x00007fff84f2b11c in objc_msgSend () #1 0x00000001000c558f in rb_objc_supports_forwarding (recv=8592468192, sel=0x100f26460) at objc.m:109 #2 0x000000010012ce3d in rb_vm_dispatch () at dispatcher.cpp:674 #3 0x00000001000d9ca1 in rb_vm_call0 (vm=0x100f23290, top=0, self=8592468192, klass=0x0, sel=0x100f26460, block=0x0, opt=2 '\002', argc=1, argv=0x7fff5fbf67c0) at vm.h:657 #4 0x00000001000dadc6 in rb_vm_call2 (block=0x0, self=8592468192, klass=0, sel=0x100f26460, argc=1, argv=0x7fff5fbf67c0) at vm.h:682 #5 0x00000001000dac66 in rb_call (recv=8592468192, mid=60, argc=1, argv=0x7fff5fbf67c0, scope=1, pass_current_block=false) at vm_eval.c:32 #6 0x00000001000dafe9 in rb_funcall (recv=8592468192, mid=60, n=1) at vm_eval.c:106 #7 0x00000001000892b1 in f_negative_p (x=8592468192) at rational.c:164 #8 0x000000010008916f in f_gcd (x=8592468192, y=139417291019515137) at rational.c:278 #9 0x0000000100089886 in f_addsub (self=8590808512, anum=18446743882439999117, aden=8592468192, bnum=18446744073164624117, bden=139417291019515137, k=45) at rational.c:652 #10 0x0000000100089df0 in nurat_sub (self=8590808512, sel=0x100f26540, other=8592438080) at rational.c:746 #11 0x000000010012e20e in __rb_vm_rcall [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:161 #12 0x000000010012e20e in ruby_dispatch [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:466 #13 0x000000010012e20e in rb_vm_dispatch () at dispatcher.cpp:886 #14 0x0000000101600414 in ?? () #15 0x0000000101604b54 in ?? () #16 0x0000000101626f84 in ?? () #17 0x0000000100134737 in __rb_vm_bcall [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:100 #18 0x0000000100134737 in vm_block_eval [inlined] () at /Users/watson/src /macruby-master/dispatcher.cpp:1248 #19 0x0000000100134737 in rb_vm_yield_args () at dispatcher.cpp:1305 (More stack frames follow...) (gdb) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/1325> MacRuby <http://macruby.org/>

1 2

[MacRuby] #1328: New Xcode project fails to build
by MacRuby 15 Jun '11

15 Jun '11

#1328: New Xcode project fails to build ----------------------------------+----------------------------------------- Reporter: mjijackson@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: macruby_deploy ----------------------------------+----------------------------------------- I started a brand new Xcode project and tried to build it, but macruby_deploy is complaining that it can't find the .app. -- Ticket URL: <http://www.macruby.org/trac/ticket/1328> MacRuby <http://macruby.org/>

1 4

[MacRuby] #1324: memory leak occurs with eval.
by MacRuby 13 Jun '11

13 Jun '11

#1324: memory leak occurs with eval. ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Test Script: {{{ #!ruby def memory pid = $$ str = `ps alx | grep '#{pid}.*ruby'` str.split[7] end Thread.start { sec = 0 loop do puts "#{sec} sec : " + memory + " KB" sleep 10 sec += 10 end } loop do eval "a = 42" end }}} Result: {{{ $ macruby eval.rb 0 sec : 13316 KB 10 sec : 70432 KB 20 sec : 124400 KB 30 sec : 189016 KB 40 sec : 228328 KB 50 sec : 312684 KB 60 sec : 352976 KB }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/1324> MacRuby <http://macruby.org/>

1 2

Re: [MacRuby] #542: Attempt to unlock a mutex which is not locked (ThreadError)
by MacRuby 13 Jun '11

13 Jun '11

#542: Attempt to unlock a mutex which is not locked (ThreadError) -------------------------------------+-------------------------------------- Reporter: valerii.hiora@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Comment(by watson1978@…): I guess that your changing is correct. the following script did not work before applying your changing in my environment. {{{ #!ruby require 'thread' m = Mutex.new r = 0 max = 100 (1..max).map{ Thread.new{ i=0 while i<max i+=1 m.synchronize{ r += 1 } end } }.each{|e| e.join } puts :finish }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/542#comment:8> MacRuby <http://macruby.org/>

1 0

Re: [MacRuby] #542: Attempt to unlock a mutex which is not locked (ThreadError)
by MacRuby 13 Jun '11

13 Jun '11

#542: Attempt to unlock a mutex which is not locked (ThreadError) -------------------------------------+-------------------------------------- Reporter: valerii.hiora@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 1.0 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- Comment(by jhemmelg@…): I took a further look through the mutex code and found what I think is part of the problem. In the file thread.c, rb_mutex_unlock0(), line 1510: {{{ pthread_assert(pthread_mutex_unlock(&m->mutex)); m->thread = NULL; }}} The assignment to m->thread is made after m->mutex is unlocked. This appears to create a race condition. I swapped these two lines and it made my test program work. {{{ m->thread = NULL; pthread_assert(pthread_mutex_unlock(&m->mutex)); }}} With this change my test program no longer fails. However, the error from running the imap test has changed: {{{ $ DYLD_LIBRARY_PATH=. ./macruby -e "require 'net/imap'; imap = Net::IMAP.new('imap.gmail.com', 993, true); imap.login('somebody','somepassword')" /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/1.9.2/monitor.rb:189:in `mon_exit': Attempt to unlock a mutex which is locked by another thread (ThreadError) from /Library/Frameworks/MacRuby.framework/Versions/0.11/usr/lib/ruby/1.9.2/monitor.rb:203:in `synchronize' from -e:1:in `<main>' }}} I took a look at the code for MonitorMixin, which imap uses for the synchronize() call. It looks like the error I am getting is impossible, because the monitor code saves and checks the thread id outside of the mutex doing the same thing. The monitor code doesn't complain about the thread id's not matching but the mutex does. I will look into this further. I can not be certain that there are no further race conditions in the mutex code. This is why this is not submitted as a patch. I have a couple of questions about the mutex implementation. I was looking into the code for mutex in the 1.9.2-p136 release and it looks fairly different. In that code the thread variable is used as the ruby- level mutex variable, and the mutex is used only to protect access to it. Why are the implementations different and would it make sense to pull that implementation over? Alternatively, would an implementation of mutex using the high-performance semaphore from GCD be worth considering? Or would it be better to just review the existing code for race conditions and move on from there? I would be happy to work on this no matter the direction, but I don't want to waste time working on something that would not be acceptable to the team. -- Ticket URL: <http://www.macruby.org/trac/ticket/542#comment:7> MacRuby <http://macruby.org/>

1 0