Hi,
On Tue, 2006-01-10 at 19:26 +0100, Mark Wielaard wrote:
Agreed. I am still hoping someone has a good analysis of the issue, or
wants to upgrade our mprec to the newlib version. If not we should
indeed disable the assert again before 0.20 is released.
Which is what I did. For now we just
Hi,
On Tue, 2006-01-10 at 01:38 +0100, Christian Thalinger wrote:
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote:
FYI,
Just testing current CVS with JCVM and I'm also getting this assertion
failure:
jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed
Christian Thalinger writes:
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote:
FYI,
Just testing current CVS with JCVM and I'm also getting this assertion
failure:
jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed.
This is on SuSE 10 on an x86 laptop
On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote:
Hmmm. mprec originally came with fdlibm from libgcj and we regarded them
as upstream, but they are now relying on us as upstream. It looks like
the original mprec imported into libgcj actually through newlib
Hi,
On Tue, 2006-01-10 at 10:17 +, Andrew Haley wrote:
Christian Thalinger writes:
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote:
Just testing current CVS with JCVM and I'm also getting this assertion
failure:
jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32
Mark Wielaard writes:
On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote:
Hmmm. mprec originally came with fdlibm from libgcj and we regarded them
as upstream, but they are now relying on us as upstream. It looks like
the original mprec imported into libgcj actually through newlib
On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote:
BTW, does anybody know why we are not using the system strtod() when
available? That seems the way to the quickest solution on most
platforms. It seems to work with some simple tests for me. But I notice
that there is no strtod_r(), just
enough with the code to understand whether
using the system strtod(3) would avoid this assertion failure, which
appears to come from Balloc in mprec.c.
-Archie
__
Archie Cobbs *CTO, Awarix* http
Mark Wielaard wrote:
On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote:
BTW, does anybody know why we are not using the system strtod() when
available? That seems the way to the quickest solution on most
platforms. It seems to work with some simple tests for me. But I notice
that there is
case, I'm not familiar enough with the code to understand whether
using the system strtod(3) would avoid this assertion failure, which
appears to come from Balloc in mprec.c.
Sorry for the noise, that email got delayed several hours for some
reason. As we now know strtod() has different behavior
Hi Archie,
On Tue, 2006-01-10 at 11:59 -0600, Archie Cobbs wrote:
In any case, we probably need to fix this before 0.20, or at least
disable the assertion (i.e., revert to the previous status quo).
Agreed. I am still hoping someone has a good analysis of the issue, or
wants to upgrade our
FYI,
Just testing current CVS with JCVM and I'm also getting this assertion failure:
jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed.
This is on SuSE 10 on an x86 laptop (Dell Latitude D810).
-Archie
On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote:
FYI,
Just testing current CVS with JCVM and I'm also getting this assertion
failure:
jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed.
This is on SuSE 10 on an x86 laptop (Dell Latitude D810).
It's interesting
Thanks to gcj's ability to compile native code that can be debugged with
gdb, I finally could narrow down and report this bug that I first
noticed with libgcj4 or libgcj5. The program runs fine under Sun's JVM,
but libgcj aborts because of an assertion failure.
I keep getting an assertion
--- Additional Comments From fitzsim at redhat dot com 2005-08-31 21:57
---
Fixed in GNU Classpath. Closing.
--
What|Removed |Added
Status|ASSIGNED
I checked in the aforementioned assertion patch.
2005-07-25 Archie Cobbs [EMAIL PROTECTED]
* native/jni/classpath/native_state.c: add assertion for object type
-Archie
__
Archie Cobbs *CTO,
Dalibor Topic wrote:
Doesn't GetObjectClass change the state of env? If that's the case, it
maybe shouldn't be an assert.
Not sure what you mean.. but there is a bug: we need to delete the
local native reference obtained by calling GetObjectClass.
Attached is a better patch.
Thanks,
-Archie
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk
Archie Cobbs wrote:
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance
Archie Cobbs wrote:
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the
object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk
With Classpath 0.16, trying to run a very simple Swing demo under JCVM,
I get a JNI assertion failure in a call to GetIntField(), because the object
type and the fieldID are not compatible:
gnu/java/awt/peer/gtk/[EMAIL PROTECTED] not instance of
gnu/java/awt/peer/gtk/GtkGenericPeer
Here
21 matches
Mail list logo
