5.0.0 jammed

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

5.0.0 jammed

alexz
I have somehow put 5.0.0 into a state with several (separate?) problems: (1) Protege starts but shows no tabs (2) On my Ubuntu 15.10, there is no (?) way to stop Protege except kill -9.  

~/.protege contains only logs directory.  Removing it does not inhibit the above mentioned behavior

protege.log

If another linux user starts Protege, the problem does not occur.
Reply | Threaded
Open this post in threaded view
|

Re: 5.0.0 jammed

Rafael Gonçalves
Hi,

The problem with the exception in the log you sent is already on our issue tracker: https://github.com/protegeproject/protege/issues/336. It’s an issue with ontology serialization views that can typically be ignored. However I cannot reproduce the frozen state that you arrived at, on a Ubuntu 16.04 (64-bit) VM running OpenJDK 1.8 and the Linux Protege distribution. I suggest temporarily removing these views from your default editor layout (since the culprit view is initialized with the editor in your case) and see if you end up with the same freezing issue. Regarding the second problem, could you be more specific as to why you cannot close Protege (a screenshot and thread dump would help)?

Cheers,
Rafael

On Jul 11, 2016, at 10:07, ramorrismorris <[hidden email]> wrote:

I have somehow put 5.0.0 into a state with several (separate?) problems: (1)
Protege starts but shows no tabs (2) On my Ubuntu 15.10, there is no (?) way
to stop Protege except kill -9.  

~/.protege contains only logs directory.  Removing it does not inhibit the
above mentioned behavior

protege.log
<http://protege-project.136.n4.nabble.com/file/n4665792/protege.log>  

If another linux user starts Protege, the problem does not occur.



--
View this message in context: http://protege-project.136.n4.nabble.com/5-0-0-jammed-tp4665792.html
Sent from the Protege User mailing list archive at Nabble.com.
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: 5.0.0 jammed

alexz
Screenshot_2016-07-11_19-38-43.png
threadDump.txt

In the shell window that started Protege via run.sh, CTRL-C is ignored.  From another shell, sig HUP via kill -1 <pid> is ignored with no message.

You suggest "removing these views from your default editor layout (since the culprit view is initialized with the editor in your case)".  How do I do this?  I am clueless what is keeping the state of my previous execution of Protege.  I find nothing in ~/.protege but logs, so I imagined that sig KILL followed by removing ~/.protege would be rather like a new installation, but the frozen behavior recurs.

Note that if I create a new Linux user and start Protege from the same installation, there is no freezing behavior

--Bob
Reply | Threaded
Open this post in threaded view
|

Re: 5.0.0 jammed

Tania Tudorache
Bob,

It looks like the Manchester Syntax Rendering view causes problems with
the initialization of the Protege user interface.

The solution would be to clean the Protege Java preferences:
http://protegewiki.stanford.edu/wiki/ClearingP4Preferences

After Protege starts again, I suggest to not enable any of the
Manchester Syntax Rendering views.

Meanwhile, we will try to reproduce the behavior on our side.

Thanks,
Tania



On 07/11/2016 04:24 PM, ramorrismorris wrote:

> Screenshot_2016-07-11_19-38-43.png
> <http://protege-project.136.n4.nabble.com/file/n4665796/Screenshot_2016-07-11_19-38-43.png>
> threadDump.txt
> <http://protege-project.136.n4.nabble.com/file/n4665796/threadDump.txt>
>
> In the shell window that started Protege via run.sh, CTRL-C is ignored.
>  From another shell, sig HUP via kill -1 <pid> is ignored with no message.
>
> You suggest "removing these views from your default editor layout (since the
> culprit view is initialized with the editor in your case)".  How do I do
> this?  I am clueless what is keeping the state of my previous execution of
> Protege.  I find nothing in ~/.protege but logs, so I imagined that sig KILL
> followed by removing ~/.protege would be rather like a new installation, but
> the frozen behavior recurs.
>
> Note that if I create a new Linux user and start Protege from the same
> installation, there is no freezing behavior
>
> --Bob
>
>
>
>
> --
> View this message in context: http://protege-project.136.n4.nabble.com/5-0-0-jammed-tp4665792p4665796.html
> Sent from the Protege User mailing list archive at Nabble.com.
> _______________________________________________
> protege-user mailing list
> [hidden email]
> https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user
Reply | Threaded
Open this post in threaded view
|

Re: 5.0.0 jammed

alexz
Thanks Tania.
The  top level directories in .java/.userPrefs are encoded in long mysterious ways, so manual search for what Protege may have set was not successful. In the end, I removed all the java support for java 6 and 7 lying around in case something in .java/.userPrefs was archaic. That alone did not change the Protege behavior, In addition running jpui-0.4.0.jar showed me no Protege.  So I bit the bullet and moved ~/.java/.userPrefs aside. Starting Protege accomplished several things:
(a). Protege seems to behave as expected as to exploring Entities
(b) Quitting via File->Exit succeeds gracefully, with a bit of  reporting about what was saved and what disposed
(c) CTRL-C causes a graceful(?)  exit in the shell window in which run.sh was executed. This doesn't expose the report generated by File-Exit
(d) A new .java/.userPrefs was created and apparently keeps history robustly and also provides the expected behavior of jpui-0.4.0.jar

So far my exercising of 5.0.0 in the fixed environment has been very limited....

I have no inherent reason to examine serializations with Protege, though I may have collaborators who want to look at our Protege-managed ontologies with other tools. I'm pretty sure I can convince them not to edit except with Protege 5....

Bob




 
Reply | Threaded
Open this post in threaded view
|

Re: 5.0.0 jammed

Tania Tudorache
Hi Bob,

Thank you for the thorough investigation.

From your description, it seems that Protege works fine, now that you deleted the preferences. I am not sure why the JPUI did not work, I am also using Ubuntu 14.04, and I could see the the protege preferences displayed (see screenshot below).

While, it should be enough to delete only the Protege preferences node, I usually just delete the entire .java/.userPrefs folder. Protege uses the Java preferences to store its configurations, and on Linux, Java creates these weird looking folders with long funny names.

Probably what happened in your case, is that there were some old preferences stored with the Manchester rendering view enabled. The preferences are global, and live through difference installations of Protege. We had some problems with the initialization of the Manchester rendering plugin, especially on Linux, but we cannot reproduce it consistently, so it is really hard to debug. We do have an open issue on it.

Once the preferences were cleared, Protege should start working fine again. It made sense that if you started protege with another user, it worked fine (because it had other preferences stored in the users' home directory)

Please let us know if you encounter other such problems.

Cheers,
Tania






On 07/13/2016 08:35 AM, ramorrismorris wrote:
Thanks Tania.
The  top level directories in .java/.userPrefs are encoded in long
mysterious ways, so manual search for what Protege may have set was not
successful. In the end, I removed all the java support for java 6 and 7
lying around in case something in .java/.userPrefs was archaic. That alone
did not change the Protege behavior, In addition running jpui-0.4.0.jar
showed me no Protege.  So I bit the bullet and moved ~/.java/.userPrefs
aside. Starting Protege accomplished several things:
(a). Protege seems to behave as expected as to exploring Entities
(b) Quitting via File->Exit succeeds gracefully, with a bit of  reporting
about what was saved and what disposed
(c) CTRL-C causes a graceful(?)  exit in the shell window in which run.sh
was executed. This doesn't expose the report generated by File-Exit
(d) A new .java/.userPrefs was created and apparently keeps history robustly
and also provides the expected behavior of jpui-0.4.0.jar

So far my exercising of 5.0.0 in the fixed environment has been very
limited....

I have no inherent reason to examine serializations with Protege, though I
may have collaborators who want to look at our Protege-managed ontologies
with other tools. I'm pretty sure I can convince them not to edit except
with Protege 5....

Bob




 



--
View this message in context: http://protege-project.136.n4.nabble.com/5-0-0-jammed-tp4665792p4665818.html
Sent from the Protege User mailing list archive at Nabble.com.
_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user


_______________________________________________
protege-user mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-user