Status fields:
| creation_ts: | 2011-12-07 17:27 |
|---|---|
| component: | vm |
| version: | default branch |
| rep_platform: | All |
| op_sys: | All |
| bug_status: | RESOLVED |
| resolution: | FIXED |
| reporter: | stefan@complang.tuwien.ac.at |
cacaojvm.org
This happens occasionally during dacapo xalan runs. The stack trace looks like this:
#7 0x00007f5df071afee in trap_handle (sig=1, xpc=0x393a484216, context=0x7f5def4c7680)
at trap.cpp:229
#8 <signal handler called>
#9 0x000000393a484216 in memcpy () from /lib64/libc.so.6
#10 0x00007f5df06f4b11 in literalstring_u2 (a=0x7f5def3e1fc0, length=18, offset=0,
copymode=true) at string.cpp:527
#11 0x00007f5df06f4b98 in javastring_intern (string=<value optimized out>)
at string.cpp:692
#12 0x00007f5df06dedac in java_lang_reflect_Method ()
at ../../src/vm/javaobjects.hpp:2494
#13 class_get_declaredmethods (c=0x7f5df05cfe00, publicOnly=true) at class.cpp:1897
The reason are the mysterious 10 bytes which are appended in a few places in string.cpp.
They are completely useless. Apparently, strings created by javastring_new don't carry
these extra bytes. When they happen to fall on a page boundary adjacent to an unmapped
page, the segfault occurs.
I already have a patch for this.
http://mips.complang.tuwien.ac.at/hg/cacao/rev/cff92704c4e0