Re: [Sablevm-developer] debbuggtk improvements and synchronization w/ gnu classpath

[David <db...@cs...>]

On Mon, Jan 19, 2004 at 05:40:54AM -0500, Grzegorz B. Prokopski wrote:
> Hi!
>=20
> I've just tried to run things from debbuggtk and there's important
> improvement - it almost starts now. After a while I get:
>=20
> $ bugviewer=20
> (java-gnome:6261): Gtk-CRITICAL **: file gtkwidget.c: line 3690
> (gtk_widget_grab_default): assertion `GTK_WIDGET_CAN_DEFAULT (widget)'
> failed
> [jni: fatal error (Local reference capacity exceeded)]
> Aborted
>=20
> $ bugwatcher=20
> [jni: fatal error (Local reference capacity exceeded)]
> Aborted
>=20

Hi Greg,

The VM has to guarantee the availability of some amount of local refs
(I think 16).  If local or not freed or a call to a special method
to increment them is not done, the VM does not have to guarantee
the availability.  It was discussed before.

So possible it is in the user code.


> (btw: shouldn't we give a stack backtrace at this point?
>  it's not really helpful as this way it's hard to say
>  where the problem actually can be)
>=20
> I am not sure whether this problem is in java-gnome itself or
> rather in GNU Classpath, but I believe I have seen some mails
> on GNU CP ML lately, that were about not using more local
> references than allowed.
>=20
> Or maybe somebody has a better idea where the problem could be?

gdb
setup a brk point on where that message is printed then
bt - for your backtrace

>=20
> Anyway - can we synchronize our SVN w/ current upstream?
> Is there any documentation how to do this properly?
>=20

You mean getting most recent CP changes?  Yes.
Look in mailing list archives, I think Etienne described
how to do it.  I think Etienne needs to add them to
some branch.

Merge should be easy as most recent changes should not affect
VM/Classpath interfaces.

> We should also start pushing our changes back upstream.
>=20

Feel free to proceed.  I already pushed a few=20
bug fixes by mailing patches on classpath mailing list.
If someone wants to work on that intensively, maybe request CP cvs write
access and contact CP on the procedure.

The next thing I would like to push is my fork/exec/Process
implementation as soon as it get more or less complete/tested
as it has nothing to do with the VM...

There would also be all the VM{Classes} that needs proper integration.
And should move some of our change upstream.

> sablevm: INTERNAL ERROR (source file "native_interface.c", line 23026):
> todo
> it's AllocObject (JNIEnv *_env, jclass cls) - so maybe it could be
> the next hole to target.
>=20

ok.  It should be easy.  Will do it sometime this afternoon.


David

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt