First steps using Soot 2.3.0 as a command-line tool
Eric | August 21, 2008This is the first of what will be a series of blog posts about frequently asked questions with using Soot. I will try to cover different topics like using Soot from the command line, as a framework and in form of its Eclipse plug-in. This is basically a user-friendly digested version of all the fabulous Soot tutorials that we have online already. Today’s topic will be on Soot’s command line and phase options.
Obtaining Soot
You can always download the latest release version of Soot from the official Soot download page. There are a bunch of different options to choose from but usually you will be needing the following:
- sootclasses-x.y.z.jar (the main Soot distribution)
- jasminclasses-x.y.z.jar (the bytecode assembler that Soot uses to create .class files)
- polyglotclasses-a.b.c.jar (the compiler front-end that Soot uses to parse .java files)
We download these three files and now we are ready to give Soot a try:
mucuna /tmp/soot $ java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar soot.Main Soot version 2.3.0 Copyright (C) 1997-2008 Raja Vallee-Rai and others. All rights reserved. ...
Bleeding-edge version (nightly build)
For the really brave among you, Ondrej Lhotak provides a nightly build that is directly drawn from our Subversion repository. Usually the latest nightly build is the most stable version of Soot because tend to test code before we commit it. However, this may not always be true.
Soot’s command line
Ok, so it seems to be working but what can we do with it now? Let’s have a look at the command line options:
mucuna /tmp/soot $ java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar soot.Main -help General Options: -h -help Display help and exit -pl -phase-list Print list of available phases -ph PHASE -phase-help PHASE Print help for specified PHASE -version Display version information and exit -v -verbose Verbose mode ...
The full list of command line options is always available here and I encourage every Soot beginner to have a look at this document.
Processing single files
Soot in general processes a bunch of classes. These classes can come in one of three formats:
- Java source code, i.e. .java files,
- Java bytecode, i.e. .class files, and
- Jimple source, i.e. .jimple files.
In case you don’t know yet, Jimple is Soot’s primary intermediate representation, a three-address code that is basically a sort of simplified version of Java that only requires around 15 different kinds of statements. You can instruct Soot to convert .java or .class files to .jimple files or the other hand around. You can even have Soot generate .jimple from .java, modify the .jimple with a normal text editor and then convert your .jimple to .class, virtually hand-optimizing your program. But we are getting off-track here…
For brevity, in the following, I will abbreviate the classpath…
sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar
by just <soot>.
The principle way to have Soot process two classes A and B is just to add them to the command line, which makes them “application classes”:
mucuna /tmp/soot $ ls *.java A.java B.java mucuna /tmp/soot $ java -cp <soot> soot.Main A B Soot started on Thu Aug 21 08:26:41 GMT-05:00 2008 Exception in thread "main" java.lang.RuntimeException: couldn't find class: A (is your soot-class-path set properly?)
Whooops, what went wrong there? Well, I omitted an important detail: Soot has its own classpath!
Soot’s classpath
Soot has it’s own classpath and will load files only from JAR files or directories on that path. By default, this path is empty and therefore in the above example Soot does not “see” the classes A and B although they exist. So let’s just add the current directory “.”:
mucuna /tmp/soot $ java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar soot.Main -cp . A B Soot started on Thu Aug 21 08:32:13 GMT-05:00 2008 Exception in thread "main" java.lang.RuntimeException: couldn't find class: java.lang.Object (is your soot-class-path set properly?)
What’s wrong now? Apparently Soot was able to find A and B (at least it doesn’t complain about these any more) but now it’s missing java.lang.Object.
Why does Soot care about java.lang.Object anyway? In order to do anything meaningful with your program, Soot needs to have typing information and in particular it needs to reconstruct types for local variables and in order to do so it needs to know the complete type hierarchy of the classes you want to process.
Regarding the exception, there are three ways to resolve it:
- add rt.jar to your classpath
- add the –pp option, given your CLASSPATH variable comprises rt.jar or JAVA_HOME is set correctly
- use the –allow-phantom-refs option (not recommended)
In the first option you add your JDK’s rt.jar to Soot’s classpath (not the JVM’s classpath!). This JAR file contains the class java.lang.Object:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp .:/home/user/ebodde/bin/sun-jdk1.6.0_05/jre/lib/rt.jar A B Soot started on Thu Aug 21 08:42:09 GMT-05:00 2008 Transforming B... Transforming A... Writing to sootOutput/B.class Writing to sootOutput/A.class Soot finished on Thu Aug 21 08:42:12 GMT-05:00 2008 Soot has run for 0 min. 3 sec.
Heureka! This seems to have worked. 
Soot successfully processed the two .java files and placed resulting .class files into the sootOutput folder. Note that in general, Soot will process all classes you name on the command line and all classes referenced by those classes.
Beware, though, a common mistake is the following:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp .:~/bin/sun-jdk1.6.0_05/jre/lib/rt.jar A B Soot started on Thu Aug 21 08:43:43 GMT-05:00 2008 Exception in thread "main" java.lang.RuntimeException: couldn't find class: java.lang.Object (is your soot-class-path set properly?)
What went wrong? Well, you tried to use “~” because that points to your home directory, no? Well yes, but the problem is that usually “~” is expanded by the shell, but not in this case. Soot gets the raw “~” string as a command line option and currently Soot is unable to expand that string into the right string for your home directory. So always use full or relative paths in Soot’s classpath. 
The second option is to use –pp:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp . -pp A B Soot started on Thu Aug 21 08:47:42 GMT-05:00 2008 Transforming A... Transforming B... Writing to sootOutput/A.class Writing to sootOutput/B.class Soot finished on Thu Aug 21 08:47:46 GMT-05:00 2008 Soot has run for 0 min. 3 sec.
Wow, that was much easier than adding this dawn classpath all the time, wasn’t it? Exactly and that’s why we added this option. –pp stands for “prepend path” and it means that Soot automatically adds the following to it’s own classpath (in that order):
- the contents of your current CLASSPATH variable,
- ${JAVA_HOME}/lib/rt.jar, and
- if you are in whole-program mode (i.e. the –w option is enabled; more to come) then it also adds ${JAVA_HOME}/lib/jce.jar
The third way (not recommended) to make Soot sort of happy is the option –allow-phantom-refs:
mucuna /tmp/soot $ java -cp <soot> soot.Main -allow-phantom-refs -cp . A B Soot started on Thu Aug 21 08:52:35 GMT-05:00 2008 Warning: java.lang.Short is a phantom class! Warning: java.lang.Class is a phantom class! Warning: java.lang.Character is a phantom class! ... Transforming B... Transforming A... Writing to sootOutput/B.class Writing to sootOutput/A.class Soot finished on Thu Aug 21 08:52:37 GMT-05:00 2008 Soot has run for 0 min. 1 sec.
So what does that do? Basically this option tells Soot: “Well, I really don’t want to give you the classes you are missing (maybe because you just don’t have those classes) but please make a best effort even without them.” Soot creates a “phantom class” for each class that it cannot resolve and tells you about it. Note that this approach is very limited and in many cases does not lead to the results you need. Only use this option if you know what you are doing.
Processing entire directories
You can also process entire directories or JAR files using Soot, using the –process-dir option:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp . -pp -process-dir . Soot started on Thu Aug 21 09:01:12 GMT-05:00 2008 Transforming A... Transforming B... Writing to sootOutput/A.class Writing to sootOutput/B.class Soot finished on Thu Aug 21 09:01:15 GMT-05:00 2008 Soot has run for 0 min. 3 sec.
To process a JAR file, just use the same option but provide a path to a JAR instead of a directory. Nice, eh? Be careful, though: If you apply the very same command again to the very same folder you will run into a problem now:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp . -pp -process-dir . Soot started on Thu Aug 21 09:02:29 GMT-05:00 2008 Exception in thread "main" java.lang.RuntimeException: Error: class A read in from a classfile in which sootOutput.A was expected.
What happened? Well, as I noted earlier, Soot places the generated .class files into the folder sootOutput, which resides in the current directory “.”. Therefore Soot now processed the previously generated files, at the same time complaining about the fact that a class of name “A” resides at location ./sootOutput/A and therefore should actually have the name sootOutput.A, i.e. be in the sootOutput package. Therefore, when using the –process-dir option also use the –d option to redirect Soot’s output:
mucuna /tmp/soot $ java -cp <soot> soot.Main -cp . -pp -process-dir . -d /tmp/sootout Soot started on Thu Aug 21 09:06:29 GMT-05:00 2008 Transforming A... Transforming B... Writing to /tmp/sootout/A.class Writing to /tmp/sootout/B.class Soot finished on Thu Aug 21 09:06:32 GMT-05:00 2008 Soot has run for 0 min. 2 sec.
This redirects Soot’s output to /tmp/sootout, which is not a sub-directory of the current directory. Voila.
Processing certain types of files (.class / .java / .jimple)
Assume you have a directory that contains both A.java and A.class and you invoke Soot as before. In this case Soot will load the definition of A from the file A.class. This may not always be what you want. The –src-prec option tells Soot which input type it should prefer over others. There are four options:
- c or class (default): favour class files as Soot source,
- only-class: use only class files as Soot source,
- J or jimple: favour Jimple files as Soot source, and
- java: favour Java files as Soot source.
So e.g. -src-prec java will load A.java in the above example.
Application classes vs. library classes
Classes that Soot actually processes are called “application classes”. This is opposed to “library classes”, which Soot does not process but only uses for type resolution. Application classes are usually those explicitly stated on the command line or those classes that reside in a directory referred to via –process-dir.
When you use the -app option, however, then Soot also processes all classes referenced by these classes. It will not, however, process any classes in the JDK, i.e. classes in one of the java.* and com.sun.*packages. If you wish to include those too you have to use the special –i option, e.g. -i java.. See the guide for this and other command line options.
Output of .jimple or .java files
Soot cannot only produce .class files, it can also produce .jimple and .java files and others. You can select the output format using the –f option. If you use –f dava to decompile to Java please make sure that the file <jre>/lib/jce.jar is on Soot’s classpath.
Phase options
Soot supports hundreds of very fine grained options that allow you to tune all the analyses and optimizations to your needs, directly from the command line.
The general format of these command line options is -p PHASE OPT:VAL. A complete document of all phase options is available here. For instance, let’s say that we want to preserve the names of local variables (if possible) when performing ana analysis within Soot. Then we can add the command line option -p jb use-original-names:true. A shortcut is -p jb use-original-names, where the true is implicitly assumed.
That’s all for today! 
Great post, Eric. This will resolve a great number of soot-list questions.
I have a question..Say I want to run soot on one of the eclipse plugins..Such plugins donot have a main so I cannot run them before using soot…I tried doing so, but it gives me wierd errors..
For example:
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at ca.mcgill.sable.soot.launching.SootThread.run(SootThread.java:138)
Caused by: java.lang.RuntimeException: couldn’t find class: JavadocInvoker (is your soot-class-path set properly?)
I set my class path, by right clicking on My computer and setting the system variable, soot.class.path=. (as mentioned in the documentation , this should allow soot to see all files in the current directory of the project)
I still get this wierd error..although it ran quite well for 2 other projects..
Please help, if you donot mind can you send me a reply on my personal email, so that I know when you reply..
Thanks alot
Hi.
You do need a main class when running Soot in whole-program mode (-w option). Unfortunately there’s no other way. Often you can make up a “mock up” main class. That worked for me in some cases.
Feel free to post questions to the Soot mailing list! That is usually the best place to ask for help.
Processing a bytecode by a library BCEL is way much better and easier than using Soot. At least it work. I spent 3 days (or should I say wasted) to make Soot run without complaing everytime but I was out of luck. My advice, guys dont use it!
Fadi I have to say that your comment offends dozens of people who have been working hard on Soot and for free for many years but I will publish it anyway. By now we believe that Soot is well documented and we have a very active mailing list on which people would usually help you within minutes in case you get stuck. If you don’t ask for help then this really is your own fault. But I believe that it’s unfair to complain in this case. What problems did you encounter? Did you read our documentation? Soot certainly seems to work for hundreds of other users.
Having said that you really cannot compare BCEL to Soot. If you are fine with using BCEL then you probably would not have wanted to use Soot in the first place as BCEL is not a program-analysis framework but merely a low-level transformation framework. BCEL is great at what it does but it fulfills a purpose much different from Soot. Try doing a whole-program pointer analysis with BCEL, that should keep you busy for at least a year. With Soot it will take a minute to set one up.
Hello,
Thank you for your great job!
I am testing the Soot against a j2me project, I am using the parameter -j2me for that, but when I install the .jar that I create from the soot classes, the mobile complains with a format error.
The tool I use to create the .jar file works because if I use the folder with the original .class files, the mobile doesn’t complain.
Can you give me a clue to send you a detailed report?
Best regards,
Jose
I am going to give the solution: execute “preverify.exe” against the classes created by soot before to create the .jar file.
Hi Jose. I am glad that you solved this yourself because I would not have known about “preverify”. Thanks for letting us know the solution.
I’m using soot to optimize my java application but I’m faced to two problems :
1- trasforming from source code throw an error during execution while transforming from correspondant byte code is ok,
2- when using transformation from byte code : classes transformed are less small than original but less efficient!!!
What happen, is not Soot a tool who better the code.
Hello.
Regarding 1) Can you please send this problem (with a stack trace) to the Soot mailing list? I am sure that we can help you out there.
Regarding 2) Soot usually does generate more efficient code already using its default settings. What makes you think that your soot-ified code is less efficient?
Eric
Hi,
I am doing some analysis using JSA. JSA uses Soot to get the Jimple representation. However, I am running into this exception -
Exception in thread “main” java.lang.RuntimeException:Error: class ivcheck.client.ClientSideValidator read in from a classfile in which ClientSideValidator was expected.
The blog mentions about this error but I am not able to still resolve it.
The classpath for Soot is set as follows :
StringAnalysis.addDirectoryToClassPath(“C:/Hersh/workspace/IVChecker/bin/ivcheck/client”);
The directory to be chosen for classes to be loaded is set as follows :
StringAnalysis.loadDirectory(“C:/Hersh/workspace/IVChecker/bin/ivcheck/client”);
Where am I going wrong? Any help would be highly appreciated.
Thanks,
Hersh
Hi Hersh.
You should include C:/Hersh/workspace/IVChecker/bin/ on the classpath, not C:/Hersh/workspace/IVChecker/bin/ivcheck/client, because the former is your class root directory.
Eric
Dear Eric,
i am trying to decompile a “.class” file using the soot, it successfully works on simple .class file example “hello world” and output .java file successfully. However on another .class file it produces the following error:
C:\Documents and Settings\wael\Desktop\Poject decompiler\soot-2.4.0>java soot.Main -f dava j8583.example.Client
Decompiling j8583.example.Client…
Exception in thread “main” java.lang.NullPointerException
at soot.dava.toolkits.base.finders.LabeledBlockFinder.perform_ChildOrder(LabeledBlockFinder.java:94)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:215)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:212)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:212)
at soot.dava.toolkits.base.finders.LabeledBlockFinder.find(LabeledBlockFinder.java:44)
at soot.dava.DavaBody.(DavaBody.java:329)
at soot.dava.Dava.newBody(Dava.java:84)
at soot.PackManager.runBodyPacks(PackManager.java:813)
at soot.PackManager.runBodyPacks(PackManager.java:454)
at soot.PackManager.runBodyPacks(PackManager.java:373)
at soot.PackManager.runPacks(PackManager.java:350)
at soot.Main.run(Main.java:198)
at soot.Main.main(Main.java:141)
C:\Documents and Settings\wael\Desktop\Poject decompiler\soot-2.4.0>
thanks for your help in advance .
Hi Roy.
I am afraid there is not much I can do about this. All I know about the de-compiler is that it is quite buggy. It can cope with a lot of different bytecode layouts but not with others.
Sorry that I cannot be of more help,
Eric
Dear Eric:
i am using the soot do decompile .class files it works on a simple .class file example :”helloworld” and it output a .java file successfully however when i pass another .class file it produces the following error:
C:\Documents and Settings\wael\Desktop\Poject decompiler\soot-2.4.0>java soot.Main -f dava j8583.example.Client
Decompiling j8583.example.Client…
Exception in thread “main” java.lang.NullPointerException
at soot.dava.toolkits.base.finders.LabeledBlockFinder.perform_ChildOrder(LabeledBlockFinder.java:94)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:215)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:212)
at soot.dava.internal.SET.SETNode.find_LabeledBlocks(SETNode.java:212)
at soot.dava.toolkits.base.finders.LabeledBlockFinder.find(LabeledBlockFinder.java:44)
at soot.dava.DavaBody.(DavaBody.java:329)
at soot.dava.Dava.newBody(Dava.java:84)
at soot.PackManager.runBodyPacks(PackManager.java:813)
at soot.PackManager.runBodyPacks(PackManager.java:454)
at soot.PackManager.runBodyPacks(PackManager.java:373)
at soot.PackManager.runPacks(PackManager.java:350)
at soot.Main.run(Main.java:198)
at soot.Main.main(Main.java:141)
C:\Documents and Settings\wael\Desktop\Poject decompiler\soot-2.4.0>
thanks for your help in advance
Roy.
Dear Eric,
just i want to know if the “dava” decompiler in you project is fully tested or not ???? shall i go on and spend more time on it or it may includes error that there is no gateway for them … ???
thank again Eric for your time but i wanna make sure about the dava decompiler cz i want to use it in a big project and i want to make sure about it first .
Hi Roy.
I did not develop Dava, therefore I am not the best person to comment on this, but I am reasonably sure that it is unfortunately *not* well tested and that it will fail on most large projects. I am afraid that dava is probably the least stable part of Soot.
Hi Eric
you were right i contact the person who actually develop dava and he told me that its under testing and its more like a thesis for now, thanks for you help, just want to ask you if you know any reliable decompiler that i can use for now ??
Regards.
Hi Roy.
Sorry but I am really not an expert on decompilers. However, I could imagine that there are more stable commercial products out there.
Hi Eric,
first of all thank you for your help about soot.
I have just installed it because i want learn to use it for a project, but for now it doesn’t work. Following this site (http://www.sable.mcgill.ca/soot/eclipse/) i have made every step in the istallation section, after this I have created a new project to test it like is writed in the guide, but when I create a new java project and it brings me in New Java Project Dialog in the Source Tab, i don’t have funtionality “Add Folder” like there is writed. I already have a Source folder called “src” have, so i continued my soot test and I created my java project. I added in src folder an example java project rather easy consisting in two file .java and it compile and run, but if I try to use each tool of soot in file, folders or project it doesn’t work and appear an information window with this message: “The chosen operation is not currently available”
What can i do? why it doesn’t work?
Thank you so much
Hi Marco.
I am not sure what is causing this error in your case. Normally, after you installed the plugin, it should be enough to just right-click on any Java file and select one of the analysis options.
Eric
Eric,
I can select a java file with a right click and choose an option, but appears an information window with the message “The chosen operation is not currently available”
I have a macbook with mac os leopard and the version of eclipse installed is 3.4.2
What can be the problem?
Marco, I am sorry but I have no idea. I have never seen this before. It works for me.
Is your Class on the project’s build path?
The project build path is in src folder of project, and src folder contains the two file .java,
is it ok?
Yes, Marco, that’s how it should be.
hard to use!God
Thanks for your comment “dt”. You know, Soot is open source. So if you have suggestions for improvement, or even time to improve on the code, by all means let us know!
Eric
Hi , Thanks for this.
This soot is extremely not user friendly ,
Can you please let me know what am I doing wrong here I’m just trying to decompile very simple java class Hello.class
[aaa@localhost temp]$ java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar:/usr/java/jdk1.6.0_23/jre/lib/jce.jar soot.Main -cp .:/usr/java/jdk1.6.0_23/jre/lib/rt.jar -f dava /home/aaa/o/forexmm/rapidsig/client/Hello.class
Exception in thread “main” java.lang.RuntimeException: couldn’t find class: javax.crypto.Cipher (is your soot-class-path set properly?)
at soot.SootResolver.bringToHierarchy(SootResolver.java:174)
at soot.SootResolver.bringToSignatures(SootResolver.java:209)
at soot.SootResolver.bringToBodies(SootResolver.java:250)
at soot.SootResolver.processResolveWorklist(SootResolver.java:135)
at soot.SootResolver.resolveClass(SootResolver.java:124)
at soot.Scene.tryLoadClass(Scene.java:359)
at soot.Scene.loadBasicClasses(Scene.java:917)
at soot.Scene.loadNecessaryClasses(Scene.java:937)
at soot.Main.run(Main.java:169)
at soot.Main.main(Main.java:145)
[aaa@localhost temp]$
Hi Rad.
jce.jar needs to be on Soot’s classpath, not on the JVM’s classpath. So, use the following:
java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar: soot.Main -cp .:/usr/java/jdk1.6.0_23/jre/lib/rt.jar:/usr/java/jdk1.6.0_23/jre/lib/jce.jar -f dava /home/aaa/o/forexmm/rapidsig/client/Hello.class
Soot is so “not user friendly” because it is deliberately explicit about what you are trying to analyze. Maybe there should be a beginners’ mode for people who do not really know or care what exactly they are doing…
Eric
Hi Eric, still doesn’t work here is what I got :-
java -cp sootclasses-2.3.0.jar:jasminclasses-2.3.0.jar:polyglotclasses-1.3.5.jar: soot.Main -cp .:/usr/java/jdk1.6.0_23/jre/lib/rt.jar:/usr/java/jdk1.6.0_23/jre/lib/jce.jar -f dava /home/aaa/o/forexmm/rapidsig/client/Hello.class
Exception in thread “main” java.lang.RuntimeException: Attempt to create RefType containing a / –> /home/aaa/o/forexmm/rapidsig/client/Hello.class
at soot.RefType.(RefType.java:53)
at soot.RefType.v(RefType.java:67)
at soot.SootClass.(SootClass.java:85)
at soot.SootClass.(SootClass.java:97)
at soot.SootResolver.makeClassRef(SootResolver.java:108)
at soot.SootResolver.resolveClass(SootResolver.java:122)
at soot.Scene.loadClass(Scene.java:390)
at soot.Scene.loadClassAndSupport(Scene.java:375)
at soot.Scene.loadNecessaryClass(Scene.java:929)
at soot.Scene.loadNecessaryClasses(Scene.java:943)
at soot.Main.run(Main.java:169)
at soot.Main.main(Main.java:145)
Hi,Eric!
I got a problem in running program with instruction:
java -javaagent:poa.jar -jar dacapo-9.12-bach.jar eclipse -s small
I was running in 32bit Window7 with 4G RAM.But it’s ok in my classmate’s Laptop with 64bit Windows7 with 4G RAM. Here is the error information from error log:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d8e4c79, pid=5036, tid=5080
#
# JRE version: 6.0_21-b07
# Java VM: Java HotSpot(TM) Client VM (17.0-b17 mixed mode windows-x86 )
# Problematic frame:
# V [jvm.dll+0x34c79]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
————— T H R E A D —————
Current thread (0x1832ac00): JavaThread “CompilerThread0″ daemon [_thread_in_native, id=5080, stack(0x184f0000,0x18540000)]
siginfo: ExceptionCode=0xc0000005, reading address 0×00000014
Registers:
EAX=0×18219830, EBX=0×00000001, ECX=0×00000000, EDX=0×18219608
ESP=0x1853f7e4, EBP=0x1853f804, ESI=0x1853fa2c, EDI=0×00000001
EIP=0x6d8e4c79, EFLAGS=0×00010293
Top of Stack: (sp=0x1853f7e4)
0x1853f7e4: 1853fa2c 17f108c0 1853fa2c 00000000
0x1853f7f4: 17ff5c68 00000000 18219830 18218fb8
0x1853f804: 1853f81c 6d8e23dc 17f108c0 18219510
0x1853f814: 17f108c0 17f108c0 1853f858 6d8e2a26
0x1853f824: 17f108c0 00000000 17f10630 1853fa2c
0x1853f834: 000000b8 1823be70 00000000 00000000
0x1853f844: 17f0a158 00000000 17f0a158 17f0a158
0x1853f854: 00018fd8 1853f89c 6d8e3e75 000000b8
Instructions: (pc=0x6d8e4c79)
0x6d8e4c69: 8d a4 24 00 00 00 00 8b 49 18 8b 0c b9 89 4d f4
0x6d8e4c79: 8b 49 14 8b 51 04 8b c7 2b c3 03 fa 8b 11 50 ff
Stack: [0x184f0000,0x18540000], sp=0x1853f7e4, free space=13d1853f300k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x34c79]
V [jvm.dll+0x323dc]
V [jvm.dll+0x32a26]
V [jvm.dll+0x33e75]
V [jvm.dll+0x344f5]
V [jvm.dll+0x34e00]
V [jvm.dll+0x323dc]
V [jvm.dll+0x32a26]
V [jvm.dll+0x33e75]
V [jvm.dll+0x34581]
V [jvm.dll+0x3487c]
V [jvm.dll+0x35e01]
V [jvm.dll+0x35f25]
V [jvm.dll+0x27d78]
V [jvm.dll+0x282fd]
V [jvm.dll+0x28428]
V [jvm.dll+0x28594]
V [jvm.dll+0x286a4]
V [jvm.dll+0x883d9]
V [jvm.dll+0x88f1f]
V [jvm.dll+0x1e6fb4]
V [jvm.dll+0x185f5c]
C [msvcr71.dll+0x9565]
C [kernel32.dll+0x4ed6c]
C [ntdll.dll+0x637f5]
C [ntdll.dll+0x637c8]
Current CompileTask:
C1:172 ! de.bodden.tamiflex.playout.rt.ReflLogger.methodMethodInvoke(Ljava/lang/Object;Ljava/lang/reflect/Method;Lde/bodden/tamiflex/playout/rt/Kind;Ljava/lang/Class;)V (305 bytes)
————— P R O C E S S —————
Java Threads: ( => current thread )
0x1830b400 JavaThread “Low Memory Detector” daemon [_thread_blocked, id=5084, stack(0x18540000,0x18590000)]
=>0x1832ac00 JavaThread “CompilerThread0″ daemon [_thread_in_native, id=5080, stack(0x184f0000,0x18540000)]
0x01b09c00 JavaThread “Attach Listener” daemon [_thread_blocked, id=5072, stack(0x17ea0000,0x17ef0000)]
0x01b06c00 JavaThread “Signal Dispatcher” daemon [_thread_blocked, id=5068, stack(0x17e50000,0x17ea0000)]
0x01afe400 JavaThread “Finalizer” daemon [_thread_blocked, id=5064, stack(0x17e00000,0x17e50000)]
0x01af9c00 JavaThread “Reference Handler” daemon [_thread_blocked, id=5060, stack(0x17db0000,0x17e00000)]
0×00559800 JavaThread “main” [_thread_in_native, id=5052, stack(0x00380000,0x003d0000)]
Other Threads:
0x01af6400 VMThread [stack: 0x00740000,0x00790000] [id=5056]
0×18182800 WatcherThread [stack: 0x18590000,0x185e0000] [id=5088]
VM state:not at safepoint (normal execution)
VM Mutex/Monitor currently owned by a thread: None
Heap
def new generation total 4928K, used 3921K [0x03d50000, 0x042a0000, 0x092a0000)
eden space 4416K, 77% used [0x03d50000, 0x040a4408, 0x041a0000)
from space 512K, 100% used [0×04220000, 0x042a0000, 0x042a0000)
to space 512K, 0% used [0x041a0000, 0x041a0000, 0×04220000)
tenured generation total 10944K, used 2530K [0x092a0000, 0x09d50000, 0x13d50000)
the space 10944K, 23% used [0x092a0000, 0×09518960, 0x09518a00, 0x09d50000)
compacting perm gen total 12288K, used 7608K [0x13d50000, 0×14950000, 0x17d50000)
the space 12288K, 61% used [0x13d50000, 0x144be1b8, 0x144be200, 0×14950000)
No shared spaces configured.
Dynamic libraries:
0×00400000 – 0×00424000 D:\Java\jdk1.6\bin\java.exe
0×77590000 – 0x776cc000 C:\Windows\SYSTEM32\ntdll.dll
0x76e60000 – 0x76f34000 C:\Windows\system32\kernel32.dll
0x756a0000 – 0x756ea000 C:\Windows\system32\KERNELBASE.dll
0x76dc0000 – 0x76e60000 C:\Windows\system32\ADVAPI32.dll
0×77200000 – 0x772ac000 C:\Windows\system32\msvcrt.dll
0x757c0000 – 0x757d9000 C:\Windows\SYSTEM32\sechost.dll
0x757e0000 – 0×75881000 C:\Windows\system32\RPCRT4.dll
0x7c340000 – 0x7c396000 D:\Java\jdk1.6\jre\bin\msvcr71.dll
0x6d8b0000 – 0x6db57000 D:\Java\jdk1.6\jre\bin\client\jvm.dll
0x75c30000 – 0x75cf9000 C:\Windows\system32\USER32.dll
0x772b0000 – 0x772fe000 C:\Windows\system32\GDI32.dll
0x76f40000 – 0x76f4a000 C:\Windows\system32\LPK.dll
0×77300000 – 0x7739d000 C:\Windows\system32\USP10.dll
0×75580000 – 0x755b2000 C:\Windows\system32\WINMM.dll
0x75d80000 – 0x75d9f000 C:\Windows\system32\IMM32.DLL
0x75f40000 – 0x7600c000 C:\Windows\system32\MSCTF.dll
0x752c0000 – 0x7530c000 C:\Windows\system32\apphelp.dll
0x6d860000 – 0x6d86c000 D:\Java\jdk1.6\jre\bin\verify.dll
0x6d3e0000 – 0x6d3ff000 D:\Java\jdk1.6\jre\bin\java.dll
0x6d340000 – 0x6d348000 D:\Java\jdk1.6\jre\bin\hpi.dll
0x75c20000 – 0x75c25000 C:\Windows\system32\PSAPI.DLL
0x6d380000 – 0x6d39a000 D:\Java\jdk1.6\jre\bin\instrument.dll
0x6d8a0000 – 0x6d8af000 D:\Java\jdk1.6\jre\bin\zip.dll
VM Arguments:
jvm_args: -javaagent:poa.jar
java_command: dacapo-9.12-bach.jar eclipse -s small
Launcher Type: SUN_STANDARD
Environment Variables:
JAVA_HOME=D:\Java\jdk1.6
CLASSPATH=.;D:\apache-ant-1.8.2\lib;D:\Java\jdk1.6\lib\tools.jar;D:\Java\jdk1.6\lib\rt.jar;
PATH=D:\apache-ant-1.8.2\bin;D:\Java\jdk1.6\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Common Files\Thunder Network\KanKan\Codecs;D:\应用软件\CTEX\UserData\miktex\bin;D:\应用软件\CTEX\MiKTeX\miktex\bin;D:\应用软件\CTEX\CTeX\ctex\bin;D:\应用软件\CTEX\CTeX\cct\bin;D:\应用软件\CTEX\CTeX\ty\bin;D:\应用软件\CTEX\Ghostscript\gs9.00\bin;D:\应用软件\CTEX\GSview\gsview;D:\应用软件\CTEX\WinEdt;D:\android-sdk-windows\tools;C:\Program Files\MySQL\MySQL Server 5.1\bin
USERNAME=Administrator
OS=Windows_NT
PROCESSOR_IDENTIFIER=x86 Family 6 Model 15 Stepping 13, GenuineIntel
————— S Y S T E M —————
OS: Windows 7 Build 7601 Service Pack 1
CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 13, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3
Memory: 4k page, physical 3144952k(1538312k free), swap 6288148k(4470872k free)
vm_info: Java HotSpot(TM) Client VM (17.0-b17) for windows-x86 JRE (1.6.0_21-b07), built on Jul 17 2010 01:10:15 by “java_re” with MS VC++ 7.1 (VS2003)
time: Sat Nov 19 20:13:02 2011
elapsed time: 5 seconds
CAN YOU HELP ME WITH THIS PROBLEM? THANKS A LOT! : )
Hello.
This is a JVM error. Are you using HotSpot? It’s notorious for those kinds of things… Maybe you should try IBM’s J9 JVM.
Eric
Dear Eric!
Thanks for your reply. Today I try it in Ubuntu with jdk version of jdk-6u29-linux-i586, it did work without error. Is there any difference between JVM of Windows and Linux? I will probably use Ubuntu instead of Windows. Anyway, thanks a lot! : )
Hi again. There can sure be differences depending on the OS. After all, we are talking about an implementation but in the VM, and the VMs differ depending on the OS.
Well, Thanks again!
Hi Eric. A really nice tutorial to get started with.
I am trying to use JBOC to obfuscate my web application code. As its a web application and I dont have a main class. I created a mock ‘Main Class’. But unfortunately this isn’t working as well. One question that I really wanted to ask is, Is it a good idea to obfuscate my web app using JBOC ?
I am using MyEclipse and I added Soot plugin, but when i am trying to process directories then I am getting exceptions like,
Exception in thread “main” java.lang.RuntimeException: couldn’t find class:
web.validate.ZipCodeValidator (is your soot-class-path set properly?)
I dont know, what to do here. I am using -process-dir with the name of the directory that holds all the compiled classes of the application.
Can you please help me with my issue. Thanks a lot.
Hi there.
Would you mind posting this question to the Soot mailing list? This here is not the appropriate place. Surely we can sort out your problem there.
Eric
Note: at least in windows, the classpath (via -cp) needs to be separated by semicolon (;) and not colon (:)
That’s awesome..
hi Eric:
I need your help!
I want to know how to run the example callGraph Soot have in its examples file,using the common line way!
Regards.
Hi. Did you look into the documentation? It’s all there… If you cannot find what you are looking for, please ask on the mailing list. Thanks!
Hi Eric :
I am a Chinese student! I feel soot is huge!
Can you give me some guid?
I am analysising the path a function go through?
ni shi na li de a ? wo ye shi zhong guo de l ,wo da de shi hanyu pingyin