resetting the path causes java_invoke to fail

[Richard Bovey]

Resetting the octave search path causes java_invoke() to fail on exit(). Example session below.

I'm using Windows XP
OCTAVE_VERSION = 3.0.1

My aim is to be able to make additions to the path, then later on to restore the path to its previous state.

Regards,
Richard

------------------

>> OCTAVE_VERSION
ans = 3.0.1
>> a = path();
>> path(a);
>> exit
error: unable to start Java VM in C:\Program Files\Java\jre1.6.0_03\bin\client\jvm.dll
error: in D:\Applications\Octave\share\octave\packages\jhandles-0.3.1\__get_object__.m near line 20, column 7:

>>> obj = java_invoke ('org.octave.graphics.HandleObject', 'getHandleObject', handle);

keyboard: stopped in D:\Applications\Octave\share\octave\packages\jhandles-0.3.1\__get_object__.m at line 20
debug>

[John W. Eaton]

On  3-Jun-2008, Richard Bovey wrote:

|
| Resetting the octave search path causes java_invoke() to fail on exit().
| Example session below.
|
| I'm using Windows XP
| OCTAVE_VERSION = 3.0.1
|
| My aim is to be able to make additions to the path, then later on to restore
| the path to its previous state.
|
| Regards,
| Richard
|
| ------------------
|
| >> OCTAVE_VERSION
| ans = 3.0.1
| >> a = path();
| >> path(a);

If there is nothing between these two lines, then I think the path
should not change.  Does it?

| >> exit
| error: unable to start Java VM in C:\Program
| Files\Java\jre1.6.0_03\bin\client\jvm.dll
| error: in
| D:\Applications\Octave\share\octave\packages\jhandles-0.3.1\__get_object__.m
| near line 20, column 7:
|
| >>> obj = java_invoke ('org.octave.graphics.HandleObject',
| >>> 'getHandleObject', handle);
|
| keyboard: stopped in
| D:\Applications\Octave\share\octave\packages\jhandles-0.3.1\__get_object__.m
| at line 20

If the path commands above don't actually change anything, then
perhaps this is a problem with initialization that happens in the
jhandles PKG_ADD file?  I don't know whether it even has one as I
don't have a Windows system on which to try to duplicate this problem,
but that's where I would start looking for problems.

jwe
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave

[Michael Goffioul-2]

On Wed, Jun 11, 2008 at 10:04 PM, John W. Eaton <jwe@...> wrote:
> If the path commands above don't actually change anything, then
> perhaps this is a problem with initialization that happens in the
> jhandles PKG_ADD file?  I don't know whether it even has one as I
> don't have a Windows system on which to try to duplicate this problem,
> but that's where I would start looking for problems.

This is the same problem as reported here:
http://www.nabble.com/Octave-2.9.13%2C-Windows%3A-path-information-stored-by-savepath-cannot-be-loaded-on-subsequent-octave-start-td12034472.html#a12035233

Basically, the path is the same, but the PKG_ADD are executed in
a different order, resulting in exit-hooks being registered in different
order. If you combine that with the interdependence between the
exit-hooks of java and jhandles packages, plus the fact that you
can't restart a new JVM within the same process, you get to the
problem reported:

1) because of PKG_ADD re-ordering, java exit-hook is scheduled
before jhandles exit-hook
2) java exit-hook terminates the JVM and clean-up resources
3) jhandles exit-hooks tries to call a Java method, automatically
restarting a new JVM (because it detects no JVM is running)
4) an error is generated, because it's impossible to start a second
JVM instance within the same process.

Michael.
_______________________________________________
Bug-octave mailing list
Bug-octave@...
https://www.cae.wisc.edu/mailman/listinfo/bug-octave