Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Dynamic variables makes app close silently without warning. #42

Closed
padi opened this Issue · 2 comments

3 participants

@padi

Based on this discussion in BW (rubymotion/BubbleWrap#151), when complete_url and opts are inside the request lambda, the app silently closes without warning. However, when you put them outside request, app runs as expected.

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:launchOptions)
    request = lambda {
      complete_url = 'http://www.colr.org/json/color/ffba13'
      opts={}
      BW::HTTP.get(complete_url, opts) do |response|
        puts 'outside block'
        BW::HTTP.get(complete_url, opts) do |resp|
          puts 'inside block'
        end
      end
    }

    BW::HTTP.get('http://www.colr.org/json/color/ffba13') do |response|
      request.call
    end
    true
  end
end
@padi padi referenced this issue in rubymotion/BubbleWrap
Closed

Nested BW::HTTP.get requests will make the app crash #151

@royaltm

I don't know if there is any progress in hunting the "local variable retain bug", but i might have isolated the cases, where retaining works and where the local variable is lost. After some hours of experimentations the repeating pattern emerges. It has something to do with the arity of the method (or the block) that the local variables are created in.

The cases:

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:opts)
    ugh
    foo
    hee
    bar
    true
  end

  def foo(dummy=nil)
    fo = "foo"
    fire = proc do
      puts "\nin the foo" # => prints "in the foo"
      puts fo.inspect # => prints "foo"
    end
    NSTimer.scheduledTimerWithTimeInterval(2,target: fire, selector: 'call:', userInfo: nil, repeats: false)
  end

  def hee(*args)
    he = "hee"
    fire = proc do
      puts "\nin the hee" # => prints "in the hee"
      puts he.inspect # => prints "hee"
    end
    NSTimer.scheduledTimerWithTimeInterval(2,target: fire, selector: 'call:', userInfo: nil, repeats: false)
  end

  def bar(&block)
    ba = "bar"
    fire = proc do
      puts "\nin the bar" # => prints "in the bar"
      puts ba.inspect # => prints "bar"
    end
    NSTimer.scheduledTimerWithTimeInterval(2,target: fire, selector: 'call:', userInfo: nil, repeats: false)
  end

  def ugh
    ug = "ugh"
    fire = proc do
      puts "\nin the ugh" # => prints "in the ugh"
      puts ug.inspect # => prints garbage or crashes, ug is gone!
    end
    NSTimer.scheduledTimerWithTimeInterval(2,target: fire, selector: 'call:', userInfo: nil, repeats: false)
  end

end

Surprisingly it seems that the problem with "lost" local variables appears only when the variables are created in the method (or block) with arity == 0. Even &block argument helps.
No matter what the order of the foo, bar, ugh... invocation is. No matter what are the timeouts. It definitely has something to do with the arity of the block or method definition.
It also doesn't matter if the arguments are provided while invoking the method (or block) or if the defaults are used.

As a proof i fixed @padi example providing simple dummy=nil argument to the first lambda.

class AppDelegate
  def application(application, didFinishLaunchingWithOptions:launchOptions)
    request = lambda { | dummy=nil | # this fixes it <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
      complete_url = 'http://www.colr.org/json/color/ffba13'
      opts={}
      BW::HTTP.get(complete_url, opts) do |response|
        puts 'outside block'
        BW::HTTP.get(complete_url, opts) do |resp|
          puts 'inside block'
        end
      end
    }

    BW::HTTP.get('http://www.colr.org/json/color/ffba13') do |response|
      request.call
    end
    true
  end
end

The above code (with the dummy=nil fix) is not crashing anymore.
Please test it and let me know if you can confirm my finding. Then i will ticket it right away to the RMBugz, maybe it will help.

@colinta
Owner

This is a very old error. closing as "fixed"

@colinta colinta closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.