Brakeman hangs scanning controllers. about brakeman HOT 14 CLOSED

Awesome. I'll dig into this.

from brakeman.

There seem to be a couple things going on here.

First clue is that it's not in an infinite loop, it's just slowing down a ton. The slow down is due to deep copying of the values. The values themselves are growing quite large.

One reason they are growing large is because of assignments inside branches, which are turned into OR'ed values. This has been greatly alleviated with my latest commit.

Another reason they are growing large is because of s += 'stuff'. Each time this is hit, the value assigned to s is growing. Because s shows up in several places, this is multiplied.

I THINK what's happening is that this state is being stored, and every time awesome gets processed as a filter it is growing larger (instead of starting with a blank slate). This is something to look into tomorrow.

However, in the meantime, I've fixed the --no-branching option so if you use that (or --faster) you can at least get around this for now.

from brakeman.

Okay, scratch my "stored state" theory. The rest is right, though. What's weird is that this is happening when running Brakeman, but not if I run the AliasProcessor (where all this is happening) manually. Strange.

from brakeman.

It seems like the issue is that awesome is both a filter and an action. Is this the case in your app?

from brakeman.

Issue still persists

from brakeman.

Hmm yeah there's a default routes warning, going to fix that and see

from brakeman.

I was able to work around this with the 1.2.2 code base (without your most recent changes) by using a local variable to do the manipulation inside the map block:

    somevar = somevar.split(",").map { |s|
      s += 'stuff' unless s =~ /regex/
      s.split('things')
    }.first

to

    somevar = somevar.split(",").map { |s|
      tmp = s
      tmp += 'stuff' unless tmp =~ /regex/
      tmp.split('things')
    }.first

I remember having issues with modifying objects when inside a iterator block in Java, I think it would throw ConcurrentModificationException.

I imagine whatever ruby does (probably making a billion copies) to get around Java's limitation is causing the hang. Even with the latest code base, it hangs until I run out of memory ~30 minutes in.

Going to use the workaround for now.

from brakeman.

Well, how Ruby handles modification of a block parameter (which this code is not really doing) would have nothing to do with Brakeman, as it's not executing the code.

However, this does narrow down the issue. The problem comes from how Brakeman is processing the assignments.

Original:

somevar = (local somevar).split(",").map do |s|
  s = ((local s) + "stuff") unless (local s) =~ /regex/
  ((local s) + "stuffstuffstuffstuffstuffstuffstuffstuff").split("things")
end.first

Using tmp:

somevar = (local somevar).split(",").map do |s|
  tmp = (local s)
  tmp = ((local s) + "stuff") unless (local s) =~ /regex/
  ((local s) or ((local s) + "stuff")).split("things")
end.first

Edit: I should be able to get this fixed tomorrow.

from brakeman.

Okay, I think I've resolved it. Please try the latest.

from brakeman.

success!

from brakeman.

Cool...unfortunately, I don't like it. It prevents detection of some simple things. I have a couple other ideas, though.

On Feb 7, 2012, at 5:03 PM, Neil Matatall [email protected] wrote:

success!

---

Reply to this email directly or view it on GitHub:
#36 (comment)

from brakeman.

Hey Neil, can you verify that the latest still works for you? Thanks!

from brakeman.

Still works, seems faster

from brakeman.

Okay, cool. Thanks.

from brakeman.