Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: JRuby 1.6RC1
-
Fix Version/s: JRuby 1.6.4
-
Component/s: None
-
Labels:None
-
Environment:MacOS X 10.6.4, JRuby master, Java 1.7 (mlvm)
-
Number of attachments :
Description
Using Java 1.7 with mlvm patchsets applied JRuby generates 'Trace/BPT trap' errors using rake, gem, or jirb commands. In addition a handful of the benchmark tests also generate this error.
I am using a build of mlvm from July 26 however I haven't tried using rake or gem with earlier versions of mlvm so this problem may or may not have been around before now.
$ git log -1
commit f6b7c2662dd97c94e3f2fc1cb7b21be59ea5d08d
Author: Hiro Asari <asari.ruby@gmail.com>
Date: Sun Jul 25 16:48:52 2010 -0700
Determine whether or not we should do reverse lookup here.
$ jruby -S gem env
Trace/BPT trap
$ jruby -S gem list rails
Trace/BPT trap
$ jruby -S rake -T
Trace/BPT trap
$ jruby -S rake test:short
Trace/BPT trap
$ jirb
Trace/BPT trap
FYI: I put a tarball of the latest Mac OS X mlvm build I am using here (fastdebug enabled):
http://www.concord.org/~sbannasch/mlvm/java-1.7.0-internal-2010_07_26.tar.gz
java -version openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2010_07_26_09_07-b00) OpenJDK Server VM (build 19.0-b03-fastdebug, mixed mode)
I also noticed that running these benchmarks in Java 1.7 (mlvm) also generated Trace/BPT Trap errors:
bench/bench_bind.rb bench/bench_chmod.rb bench/bench_erubis.rb bench/bench_file_writing.rb bench/bench_io_open.rb bench/bench_io_read.rb bench/bench_io_sysread.rb bench/bench_io_tcpsocket.rb bench/bench_lazy_method_triggers.rb bench/bench_parser.rb bench/bench_rake_install.rb bench/bench_rexml.rb bench/bench_stat.rb bench/bench_tempfile.rb bench/bench_time_require.rb bench/bench_xml_builder.rb bench/bench_yaml.rb
This is an issue in our native subsystem. The binary we ship with for darwin is not compatible with the Java 7 builds I've tried. Perhaps because it's a fat OS X library and the OpenJDK builds don't know how to cope with that?