DSA Analysis

Hi,

I'm still using the release_26 version of Poolalloc/DSA with llvm 2.6 for my analyses and am currently trying to switch to llvm 2.7 for several reasons. I tried to use the trunk of the poolalloc svn repository with the llvm 2.7 release which is working fine for most of the programs I ran it on so far but for sqlite it's running into a stack overflow since it is endlessly looping in the BUDataStructure::calculateGraphs method (excerpt of the debugging output is attached).

Since it is actively worked on I'm not asking for a quick solution. I just wanted to send this for case this behavior is not expected and to ask if there is a revision for which the BU DSA is known to work at least stable in most cases such that I can work with llvm 2.7. Or is there any plan on when a stable version for 2.7 (or even better 2.8) will be available?

Anyway, thanks for your great work on llvm and dsa.

Cheers, Kevin

Hi,

I'm still using the release_26 version of Poolalloc/DSA with llvm 2.6 for my analyses and am currently trying to switch to llvm 2.7 for several reasons. I tried to use the trunk of the poolalloc svn repository with the llvm 2.7 release which is working fine for most of the programs I ran it on so far but for sqlite it's running into a stack overflow since it is endlessly looping in the BUDataStructure::calculateGraphs method (excerpt of the debugging output is attached).

Yep, I'm familiar with the error. Does this still happen after the
commits from last night?

Since it is actively worked on I'm not asking for a quick solution. I just wanted to send this for case this behavior is not expected and to ask if there is a revision for which the BU DSA is known to work at least stable in most cases such that I can work with llvm 2.7. Or is there any plan on when a stable version for 2.7 (or even better 2.8) will be available?

Thanks for understanding that it's a work-in-progress, and appreciate
the report. I don't believe there's a stable revision for 2.7, that's
what we're working for presently :).

If you'd like, feel free to send me the bitcode file and I can try to
prioritize fixing the issue you're seeing if it's not fixed already.
Alternatively consider filing a bugreport, both DSA and poolalloc have
projects on the bug tracker (http://llvm.org/bugs), so we can take
care of it... and again an example demonstrating your issue is
appreciated if possible.

Hope this helps,

~Will Dietz

Kevin Streit wrote:

Hi,

I'm still using the release_26 version of Poolalloc/DSA with llvm 2.6 for my analyses and am currently trying to switch to llvm 2.7 for several reasons. I tried to use the trunk of the poolalloc svn repository with the llvm 2.7 release which is working fine for most of the programs I ran it on so far but for sqlite it's running into a stack overflow since it is endlessly looping in the BUDataStructure::calculateGraphs method (excerpt of the debugging output is attached).
  
This is a known bug (PR#7929 at http://llvm.org/bugs/show_bug.cgi?id=7929). You can work around this problem by using the -dsa-no-filter-callcc=true, -dsa-no-filter-vararg=true, and -dsa-no-filter-intfp=true options. Apparently Will has already fixed it, so the work-around isn't necessary.

That said, there is a bug (we believe it is in BU) that causes memory explosion on some programs (like 176.gcc). You may run into that bug once you set the above command line options. We're still working on diagnosing and fixing that bug.

Since it is actively worked on I'm not asking for a quick solution. I just wanted to send this for case this behavior is not expected and to ask if there is a revision for which the BU DSA is known to work at least stable in most cases such that I can work with llvm 2.7. Or is there any plan on when a stable version for 2.7 (or even better 2.8) will be available?
  
In general, we try to keep mainline DSA working (i.e., no regressions). I don't foresee us introducing any major regressions or instability, but it is possible that we may do some refactoring in the near future (next 6 months) that may introduce regressions. Using mainline DSA and LLVM 2.7 will probably be fine, but if you want zero regressions, then I recommend using the release_26 branch of DSA as we are no longer enhancing it.

As for when there will be a stable DSA for LLVM 2.7, there is no concrete plan per se. The current plan is to keep fixing bugs and keep trying it on more programs. The best answer I can give is that it will be done when it is finished.
:slight_smile:

An update to the LLVM 2.8 API is not planned yet because we're focusing on making DSA and Poolalloc more robust. Updating to LLVM 2.8 isn't necessary (yet) and would just complicate the bug finding/fixing process.

Anyway, thanks for your great work on llvm and dsa.
  
Thanks. We're hoping that this effort to get DSA/Poolalloc robust will be a benefit to both our research and, some day, for the community at large.

-- John T.

Hi,

Kevin Streit wrote:

Hi,

I’m still using the release_26 version of Poolalloc/DSA with llvm 2.6 for my analyses and am currently trying to switch to llvm 2.7 for several reasons. I tried to use the trunk of the poolalloc svn repository with the llvm 2.7 release which is working fine for most of the programs I ran it on so far but for sqlite it’s running into a stack overflow since it is endlessly looping in the BUDataStructure::calculateGraphs method (excerpt of the debugging output is attached).

This is a known bug (PR#7929 at http://llvm.org/bugs/show_bug.cgi?id=7929). You can work around this problem by using the -dsa-no-filter-callcc=true, -dsa-no-filter-vararg=true, and -dsa-no-filter-intfp=true options. Apparently Will has already fixed it, so the work-around isn’t necessary.

Oh, sorry. Didn’t find that bug.
Will Dietz asked me to send him my Bitcode file since the problem is still there in the current revision (111918).

Anyway, thanks for your great work on llvm and dsa.

Thanks. We’re hoping that this effort to get DSA/Poolalloc robust will be a benefit to both our research and, some day, for the community at large.

DSA is already a great benefit for us and I’m sure that making it more robust will be too.

Cheers,
Kevin Streit

Fixed with respect to the bug description and the provided test case,
and I believe in all such bugs due to filtering.

Note that even with these options (disabling filtering) his test case
still fails--it would appear that while this has the same symptom
(calculateGraphs infinitely recursing) it's not because of the same
thing (filtering callees).

So this might deserve its own bug report, shrug, not sure best policy
here. Either way we should fix it :).

~Will