-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P1
-
Affects Version/s: 1.1, 1.1.2
-
Component/s: core-libs
-
None
-
1.1.5
-
other, sparc
-
solaris_2.4, solaris_2.5
-
Verified
[From Alan Bishop at WebTV. He discovered this problem while working on
their implementation of PersonalJava. Their implementation happens
to be JavaSoft's reference implementation, and it's important that this get fixed very soon. Alan's either compiling for MIPS or PPC; I neglected to ask which.]
The serialization native code is flawed. It does not use the
GET_INT64, SET_INT64, GET_DOUBLE, and SET_DOUBLE macros defined in
typedefs.h. Therefore, it dumps core when compiled with a compiler
that uses doubleword load and store instructions on a platform that
wants 8 byte alignment for such types. Sparcs and GCC are such a
combination.
So, we need to figure out who is going to fix this. I would prefer if
the folks responsible for the mistake to start with took care of it.
If you think it unlikely that you can get them to do it, I might be
convinced to fix it.
It's not that much work, but I imagine that the folks over there are
better set up with tests to verify that no one breaks anything when
mucking around with the code.
their implementation of PersonalJava. Their implementation happens
to be JavaSoft's reference implementation, and it's important that this get fixed very soon. Alan's either compiling for MIPS or PPC; I neglected to ask which.]
The serialization native code is flawed. It does not use the
GET_INT64, SET_INT64, GET_DOUBLE, and SET_DOUBLE macros defined in
typedefs.h. Therefore, it dumps core when compiled with a compiler
that uses doubleword load and store instructions on a platform that
wants 8 byte alignment for such types. Sparcs and GCC are such a
combination.
So, we need to figure out who is going to fix this. I would prefer if
the folks responsible for the mistake to start with took care of it.
If you think it unlikely that you can get them to do it, I might be
convinced to fix it.
It's not that much work, but I imagine that the folks over there are
better set up with tests to verify that no one breaks anything when
mucking around with the code.
- duplicates
-
JDK-4031520 Alignment error in native code for long long.
-
- Closed
-