ERROR: Unknown entry kind: Array.newInstance
Ganesha Upadhyaya
Eric Bodden
Unfortunately, at the moment TamiFlex is a bit ahead of Soot. Soot
currently only supports reflective calls of the following kinds:
Class.forName
Class.newInstance
Constructor.newInstance
Method.invoke
Field.set*
Field.get*
You code contains a call to Array.newInstance, which Soot does not yet
know how to handle.
There are two options to this:
1) Modify Soot to handle this call. (A contribution would be greatly
appreciated here.)
2) Configure TamiFlex to not monitor Array.newInstance calls. This
would make Soot unsound in the respective call sites, of course.
To do the latter, you have to modify ~/.tamiflex/poa.properties. You
will find an entry...
transformations =\
de.bodden.tamiflex.playout.transformation.array.ArrayNewInstanceTransformation
\
de.bodden.tamiflex.playout.transformation.array.ArrayMultiNewInstanceTransformation
\
de.bodden.tamiflex.playout.transformation.clazz.ClassForNameTransformation
\
de.bodden.tamiflex.playout.transformation.clazz.ClassGetDeclaredFieldsTransformation
\
...
Remove all the lines corresponding to entries that Soot currently does
not support.
I will have to update the online documentation accordingly, I guess.
Let me know if that works for you.
Eric
--
Eric Bodden, Ph.D., http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Principal Investigator in Secure Services at CASED
Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
Ganesha Upadhyaya
Eric Bodden
On 14 January 2012 07:18, Ganesha Upadhyaya <ganes...@gmail.com> wrote:
> Hi Eric,
>
> Thanks for the immediate help. It worked after removing multiple
> transformations. I am trying to reproduce what you have reported in the
> tamiflex recent paper where I want to produce sound static callgraph when
> compared to dynamic callgraph. Another point where I'm kind of stuck is,
> producing dynamic callgraph using your jvmti agent. I have compiled the
> agent and used it while running avrora with small setting, and it takes too
> much time to produce the trace file with method CALL entries. I'm running
> following command:
> java -agentpath:./target/tracer.so=trace.txt -jar
> ../../tamiflex/dacapo-9.12-bach.jar avrora -s small
It may well be the case that this takes really long. I remember that
for the experiments in our ICSE paper we ran the agent for several
days, actually. (On a fast compute server, that is.)
> Output: It did produce trace file of 14MB, but program doesn't terminate (I
> do expect this large file, as your reported files in the repository are that
> huge too). Do you suspect any problem in my execution? (I would like to
> mention that, I do have enough powerful machine to test these)
I guess it may actually terminate eventually, it may just take a
really long time. Note that usually it should not be necessary to run
the JVMTI agent. The point of our experiments was to do this *once* to
show that if tamiflex is used correctly, and all calls that tamiflex
monitors are taken into account, then this is sufficient to get a call
graph that is representative of all monitored runs.
Eric
Andreas Sewe
as I was the one who wrote the JVMTI agent for our paper, here are my 2
cents:
>> Thanks for the immediate help. It worked after removing multiple
>> transformations. I am trying to reproduce what you have reported in the
>> tamiflex recent paper where I want to produce sound static callgraph when
>> compared to dynamic callgraph. Another point where I'm kind of stuck is,
>> producing dynamic callgraph using your jvmti agent. I have compiled the
>> agent and used it while running avrora with small setting, and it takes too
>> much time to produce the trace file with method CALL entries. I'm running
>> following command:
>> java -agentpath:./target/tracer.so=trace.txt -jar
>> ../../tamiflex/dacapo-9.12-bach.jar avrora -s small
>
> It may well be the case that this takes really long. I remember that
> for the experiments in our ICSE paper we ran the agent for several
> days, actually. (On a fast compute server, that is.)
Yes, the JVMTI agent was not designed to be fast (relatively verbose,
human-readable output; possibly high contention for a largish critical
section:
<http://code.google.com/p/tamiflex/source/browse/jvmti-tracer/src/tracer.c?repo=benchmarks#43>);
it was simply designed for a one-off experiment.
What it was designed for, however, was to be straight-forward. Maybe
some added printf-statements can give already you an idea where the
problem may be.
>> Output: It did produce trace file of 14MB, but program doesn't terminate (I
>> do expect this large file, as your reported files in the repository are that
>> huge too). Do you suspect any problem in my execution? (I would like to
>> mention that, I do have enough powerful machine to test these)
>
> I guess it may actually terminate eventually, it may just take a
> really long time.
Can you produce a thread-dump (with kill -3 $JAVA_PID) to see where it
hangs? I haven't experienced any deadlocks, personally, but that doesn't
mean there are none.
Hope this helps.
Andreas
rogerl...@gmail.com
Roger
在 2012年1月13日星期五UTC+11下午6时40分25秒，Eric写道：
Eric Bodden
This does not make much sense. If you commented out a class then TamiFlex should *not* be looking for this class any longer. Maybe there's an issue with whitespace or so in your config file?
Eric
> You received this message because you are subscribed to the Google Groups "tamiflex-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to tamiflex-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
rogerl...@gmail.com
在 2013年5月7日星期二UTC+10下午4时12分38秒，Eric Bodden写道：
Aritra Sengupta
Roger Lee
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tamiflex-discuss/6q6ShId_TIw/unsubscribe.--
You received this message because you are subscribed to a topic in the Google Groups "tamiflex-discuss" group.
To unsubscribe from this group and all its topics, send an email to tamiflex-discu...@googlegroups.com.
