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 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 mpr
calls.
In any 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 s
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
'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.
-Archie
__
Archie Cobbs *
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(), ju
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
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:
> > >
> > &g
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
> (http://sourceware.org/ne
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 &l
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
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 o
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 Latit
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
--- 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, Awa
Archie Cobbs wrote:
> 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.
>
> Attac
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:
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
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:
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 is
22 matches
Mail list logo
