Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Michael Eichberg
@Delors
How do you load the library? The method body should only be None if the method doesn’t have one (native or abstract) or if it is discarded while loading it. BTW libraryClassFilesAreInterfacesOnly actually doesn’t change how the classes are loaded - it basically reflects how the classes are expected to be loaded. That is, it might be possible that the “discarding" loader was used but libraryClassFilesAreInterfacesOnly is still false.
Alexander Gössl
@majestocx
Ok i will check wether the method is native / abstract. This is how the librarie is loaded:
val libraryClassFiles = Java9LibraryFramework.AllClassFiles(opalInit.libraries.map(new File(_)) :+ org.opalj.bytecode.RTJar )
Michael Eichberg
@Delors
ok…. Java9LibraryFramework kills the method bodies
you should use the “normal” Java9Framework
it is interessting that libraryClassFilesAreInterfacesOnly is false … there is clearly some issue somewhere!
Alexander Gössl
@majestocx
Ok now my Tests need some extra Memory but i still get the same exception:
nfo] - Load Project with jdk and libraryClassFilesAre not InterfacesOnly FAILED
[info] "java.util.NoSuchElementException: None.get
[info] at scala.None$.get(Option.scala:366)
[info] at scala.None$.get(Option.scala:364)
[info] at org.opalj.tac.TACNaive$.apply(TACNaive.scala:70)
[info] at org.opalj.tac.ToTxt$.$anonfun$apply$9(ToTxt.scala:319)
[info] at scala.Option.getOrElse(Option.scala:138)
[info] at org.opalj.tac.ToTxt$.apply(ToTxt.scala:318)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2(OPALProject.scala:124)
[info] at opal.extension.vscode.OPALProject.$anonfun$getTacForClass$2$adapted(OPALProject.scala:116)
[info] at org.opalj.collection.immutable.RefArray.foreach(RefArray.scala:289)
[info] at opal.extension.vscode.OPALProject.getTacForClass(OPALProject.scala:116)
Michael Eichberg
@Delors
First - have you tried using the AI based variant of the TAC instead of TACNaive? If the first one works, it is a bug in the latter :-)
If does work with TACAI but doesn’t work with TACNaive can you tell which class causes the troubles?
Alexander Gössl
@majestocx
Unfortunately it does not work with both options...
The error occurres at the TACNaive.scala at Line 70: val code = method.body.get (body is None)
Michael Eichberg
@Delors
Hi Everybody, I just wanted to let you know that I just updated all subprojects to make them compatible with Java 11. That is, all projects can now be compiled and run on Java 11. Furthermore, Hermes (Core) doesn’t have any relevant JavaFX dependencies anymore. Given that all JavaFX libs are pulled from Maven, it should now be possible to build all of OPAL even in headless settings. (Of course, executing the Hermes UI requires a proper/complete JavaFX installation.)
BTW If you want to run the Hermes UI, don’t use the Eclipse J9 JVM - at least I didn’t get it working.
Ben Hermann
@bhermann
That is great! Especially the headless option is very helpful for me! Thank you!
mariotrageser
@mariotrageser
Bildschirmfoto 2019-05-04 um 14.33.55.png
Michael Eichberg
@Delors
Hi - such a bug may happen if you use the same (fully qualified) class name in different projects.
mariotrageser
@mariotrageser
When IntelliJ tries to compile OPAL, I get this error since one week.
I have to remove the sub modules „Demos“ and „Validate“ from the project every time. They seem to be duplicates of „OPAL-Developer Tools“ and „OPAL-Validate“. Did you change the project structure in the last days?
Michael Eichberg
@Delors
yes I did
you may have to reimport everything
mariotrageser
@mariotrageser
Ok, I try to do so. Thank you
Are Demos and Validate the new projects, which replace the two others?
Michael Eichberg
@Delors
Not exactly
Demos exists “forever"
OPAL-Validate => Validate
mariotrageser
@mariotrageser
I meant Tools and OPAL-Developer Tools. So „OPAL-Developer Tools“ should also no longer exist?
Michael Eichberg
@Delors
OPAL-DeveloperTools => Tools
Yes
mariotrageser
@mariotrageser
I had to remove them manually, but now everything works. Thank you
Javor Nikolov
@bubbazz
there is a way to get the current program counter from the classes "SimpleBranchInstruction" and "LOOKUPSWITCH".
Michael Eichberg
@Delors
No - this information is generally only implicitly available. If you use Code’s iterate and foreach methods you are always provided with the current pc. Does this help? If not, can you provide us with a short sample?
ewontfix
@ewontfix
Is there an easy way to get all primitive expressions (expressions which don't contain subexpressions) which occur in a TAC Stmt? Stmt.forallSubExpression seems to be a bit overkill for this use case.
Michael Eichberg
@Delors
In general, the TAC code is flat; i.e., a statement’s expressions are either Vars or Consts - that’s it. (OPAL has the ability to represent nested (sub) expressions, but this feature is reserved for future usage related to decompling code.) Hence, Stmt.forallSubExpression combined with a simple match over the two mentioned types of expressions should be sufficient in most to all cases. Does this help?
ewontfix
@ewontfix
Yes, thanks. My Code already works with Stmt.forallSubExpressions. It just takes somewhat longer than expected to execute and I guessed unnecessary exploring of a lot of intermediate expressions might be the cause. But if expressions are already flat, there is probably another cause.
Michael Eichberg
@Delors
One of the most frequent sources of performance isssues that I see when people use OPAL is the “naive” usage of Scala collections.
For example: val x = Set(..); x.filter(…).map(..).toList creates two intermediate sets before the list is finally created. Rewriting such code to avoid the creation of intermediate collections (e.g., by using foldLeft and withFilter) can lead to very significant performance improvements. But, this is only a wild guess given that I don’t know your code at all...
ewontfix
@ewontfix
To be more specific: I'm working on exercise 4 in APSA. My Analysis works for the provided AllocationFreeness class. But each time I run it against the whole JDK (rt.jar) it fails with an OutOFMemoryError after roughly 7 minutes. I stripped down my analysis step by step. Now I have reached a minimal bare-bones version, in which the analyze method immediately returns a Result. Still if I run this analysis against the JDK it fails with the same error. This is the complete code of my stripped down analyze method:
def analyze(method: DeclaredMethod): PropertyComputationResult = {
    if (!method.hasSingleDefinedMethod)
      return Result(method, MethodWithAllocations);

    if (method.definedMethod.isNative)
      return Result(method, MethodWithAllocations);

    return Result(method, MethodWithAllocations);
  }
ewontfix
@ewontfix
Here's the full diff against the provided template for this version:
44,45c44,45
<     allocationFreeMethods.map(_.e).mkString("allocation free: ", "\nallocation free: ", "\n")+
<     methodsWithAllocations.map(_.e).mkString("with allocations: ", "\nwith allocations: ", "\n")+
---
> //    allocationFreeMethods.map(_.e).mkString("allocation free: ", "\nallocation free: ", "\n")+
> //    methodsWithAllocations.map(_.e).mkString("with allocations: ", "\nwith allocations: ", "\n")+
65c65
<     ???
---
>     return Result(method, MethodWithAllocations);
Am I correct that at least this really minimal code should work?
roterEmil
@roterEmil
I had the same problem, that the analysis works on the given AllocationFreeness class but gets an OutOFMemoryError when running it against the JDK. When running the given template without my analysis against the JDK it also gets this error.
Michael Eichberg
@Delors
When you want to analyze the JdK you should at least allocate 6gb to the analysis! Depending on the concrete Analysis even much more memory may be required
David Kretzmer
@david-k_gitlab
Hi, I don't quite understand how to specify the entry points. In particular, what is the meaning of the Fact that must be associated with a DeclaredMethod in entryPoints?
Florian Kübler
@florian-kuebler
Without spoiling the solution:
The IFDS algorithm is a graph reachability problem, and the map of entrypoints specifices the starting points for the graph exploration.
More specific that are the Methods and Facts that are true before analyzing the methods. If these facts do not need to store any specific information, tautology facts are used.
Does that help?
David Kretzmer
@david-k_gitlab
Thanks, in principal I understand this, I'm just a bit confused that we can specify only one Fact per DeclaredMethod, and so I don't really know how I would provide initial facts for e.g. the parameters.
Florian Kübler
@florian-kuebler
You should could consider the tautology fact in taint analysis as something expressing: This is not tainted, but this statement/method is reachable and a taint could be generated from here.
However, later on you should also propagate taints into parameters, and you are not restricted to one Fact per DeclaredMethod when propagating facts.
David Kretzmer
@david-k_gitlab
Thanks for trying to help me understand! Currently, I think my main confusion is that, if I understand the original IDFS paper correctly, then the tautology fact (represented by a bold zero in the paper) is more of an implementation detail of the IDFS algorithm and not something that you would use directly in the dataflow functions. So why would I need to specify a tautology fact when I only work with dataflow functions?
(I think this question is rather general and doesn't require spoiling the solution, but correct me if I'm wrong.)
Dominik Helm
@errt
It is not just an implementation detail. Your analysis needs some kind of starting condition and as, at least in OPAL, you can only start at methods' starts, you need some fact that is valid at that point. Now if your analysis tries e.g. to track parameters of public methods, you can use these, but if you are searching for taint sources that might be inside a method, you need that tautological fact.
David Kretzmer
@david-k_gitlab
Okay, if you think about it as a graph reachability problem, then this makes sense to me. But when thinking about dataflow functions (and this seems to be the level of abstraction of AbstractIFDSAnalysis) then I don't see why a tautological fact is needed. I probably haven't really understood how this all works, so I will do some more reading and thinking and then ask a more concrete question if needed. Thanks!
Mehdi
@ashkboos

Hi- I am using:

     <artifactId>bytecode-representation_2.11</artifactId>
     <version>0.8.15</version>

as a maven dependency in a java application. It's working on tests, IDE and jar file with a specified classpath, but while running my application as a runnable jar-with-dependencies it throws this error No configuration setting found for key 'org.opalj.analysisMode'. Please let me know if anyone knows how to fix this.