[poa] Segfault when executing fop benchmark

28 views
Skip to first unread message

Pascal Wittmann

unread,
Jan 27, 2012, 5:55:53 AM1/27/12
to tamiflex...@googlegroups.com
Hi,

I executed the play-out-agent (version 2.0.0.0) together with the 'fop'
benchmark included in scalabench (version 0.1.0-SNAPSHOT) and got a
segfault.

This is how I executed tamiflex:

% java -javaagent:poa-2.0.0.0.jar -jar
~/.m2/repository/org/scalabench/benchmarks/scala-benchmark-suite/0.1.0-SNAPSHOT/scala-benchmark-suite-0.1.0-SNAPSHOT.jar
fop

And this is the resulting output:

============================================================
TamiFlex Play-Out Agent Version 2.0.0.0
Loaded properties from /home/pascal/.tamiflex/poa.properties
============================================================
===== DaCapo 0.1.0-SNAPSHOT fop starting =====
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb6f7478e, pid=18554, tid=2412772160
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) Server VM (21.0-b17 mixed mode linux-x86 )
# Problematic frame:
# V [libjvm.so+0x52478e] JVM_FindSignal+0xe6b9e
#
# Failed to write core dump. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /home/pascal/sandbox/hs_err_pid18554.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
zsh: abort java -javaagent:poa-2.0.0.0.jar -jar fop
java -javaagent:poa-2.0.0.0.jar -jar fop 77.29s user 1.18s system 137%
cpu 57.126 total

The error report file is attached, the core dump is too big (119MB) to
attach. But I'm located at the TU Darmstadt, so there are ways to get it
to you if necessary.

When using the benchmarks batik, pmd and xalan everything works fine.

Furthermore when deleting the transformation

de.bodden.tamiflex.playout.transformation.method.MethodGetNameTransformation

from ~/.tamiflex/poa.properties the segfault does not appear.

On a friends mashine with openjdk this segfault does not appear, but I
can not remember the version of openjdk and have no openjdk at hand.

Just ask if you need further information.

hs_err_pid18554.log
signature.asc

Eric Bodden

unread,
Jan 27, 2012, 6:03:27 AM1/27/12
to tamiflex...@googlegroups.com
Hello Pascal.

Thanks for your feedback. Segfaults are typically the VM's fault, but
nevertheless we could probably try to come up with a workaround. Could
you let me know where I can download the suite?

Cheers,
Eric

On 27 January 2012 11:55, Pascal Wittmann

--
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

Pascal Wittmann

unread,
Jan 27, 2012, 6:19:31 AM1/27/12
to tamiflex...@googlegroups.com
On 01/27/2012 12:03 PM, Eric Bodden wrote:
> Thanks for your feedback. Segfaults are typically the VM's fault, but
> nevertheless we could probably try to come up with a workaround. Could
> you let me know where I can download the suite?

Thanks for your fast response!

You can download the scala-benchmark-suite at:

http://repo.scalabench.org/snapshots/org/scalabench/benchmarks/scala-benchmark-suite/0.1.0-SNAPSHOT/

signature.asc

Andreas Sewe

unread,
Jan 27, 2012, 8:46:09 AM1/27/12
to tamiflex...@googlegroups.com, Pascal Wittmann
Hi Eric, hi Pascal,

For the record: the Scala Benchmark Suite we developed is a strict
superset of the DaCapo 9.12 benchmark suite; it just reuses the DaCapo
harness and includes all its benchmarks (like fop). So, you should be
able to reproduce this also with the plain DaCapo suite.

Hope that clarifies things and gives credit where credit is due.

Best wishes,

Andreas

signature.asc

Eric Bodden

unread,
Jan 29, 2012, 12:03:00 PM1/29/12
to tamiflex...@googlegroups.com
Hi Pascal and others.

It turns out that indeed there was something wrong with the way we
instrumented this method. We were using an "ALOAD 1" although there is
no parameter/local variable 1 for Method.getName(). This is fixed now.
Thanks for reporting.

Eric

On 27 January 2012 12:19, Pascal Wittmann

--

Pascal Wittmann

unread,
Jan 29, 2012, 12:12:30 PM1/29/12
to tamiflex...@googlegroups.com
On 01/29/2012 06:03 PM, Eric Bodden wrote:
> Hi Pascal and others.
>
> It turns out that indeed there was something wrong with the way we
> instrumented this method. We were using an "ALOAD 1" although there is
> no parameter/local variable 1 for Method.getName(). This is fixed now.
> Thanks for reporting.
>
> Eric

Cool, thank you!


Pascal

signature.asc
Reply all
Reply to author
Forward
0 new messages