Modify

Opened 9 years ago

Closed 8 years ago

Last modified 16 months ago

#11209 closed defect (othersoftware)

Keyboard input stops working after a few minutes

Reported by: andrewpmk@… Owned by: team
Priority: critical Milestone:
Component: Core Version: tested
Keywords: keyboard input focus linux ibus javabug Cc: asbjorn.syverhuset@…, jbcorbeille-josm@…, dieterdreist, akks, Atalanttore

Description

After editing in JOSM for a few minutes, all keyboard input stops working. This makes it impossible to enter tags, use keyboard shortcuts, etc. I am using Ubuntu 14.10 on a Lenovo T440 laptop. This is true both in josm-tested version 8109 and josm-latest version 8117.

Please provide any additional information below. Attach a screenshot if possible.

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2015-03-02 02:30:58
Last Changed Author: Don-vip
Revision: 8109
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2015-03-02 00:13:51 +0100 (Mon, 02 Mar 2015)
Last Changed Rev: 8109

Identification: JOSM/1.5 (8109 en) Linux Ubuntu 14.10
Memory Usage: 361 MB / 910 MB (168 MB allocated, but free)
Java version: 1.7.0_75, Oracle Corporation, OpenJDK 64-Bit Server VM
Java package: openjdk-7-jre:amd64-7u75-2.5.4-1~utopic1
Dataset consistency test: No problems found

Attachments (14)

Console.txt (506.5 KB ) - added by JB 9 years ago.
Console output, june 3rd, 21h.
Console2.txt (114.6 KB ) - added by JB 9 years ago.
Console3.txt (43.9 KB ) - added by anonymous 9 years ago.
Console4.txt (66.5 KB ) - added by JB 9 years ago.
Console5.txt (168.4 KB ) - added by anonymous 9 years ago.
josm-input-stuck-debug.txt (22.9 KB ) - added by alv 9 years ago.
totally unresponsive in the end
josm-debug-ui-add-tag-stuck-01.txt (55.2 KB ) - added by alv 9 years ago.
dialog stuck in the middle, then recovered
ButTheBugIsStillPresent.patch (2.5 KB ) - added by akks 9 years ago.
Even after applying this patch I can reproduce the bug on Linux by mdk's method.
ButTheBugIsStillPresent2.patch (2.9 KB ) - added by akks 9 years ago.
I tried disabling AdvancedKeyDetector completely and replacing EditTagDialog with simple mock JOptionPane.showInputDialog/ The bug is the same! It is not related to ialog specifics - any frequently opened and closed dialog with text input can hang the keyboard.
ButTheBugIsStillPresent3.patch (2.9 KB ) - added by akks 9 years ago.
(I am afraid we cannot do anything to work-around the bug on Linux in JOSM code. Here is the trivial version and with it the keyboard still hangs after pressing Enter in tag table multiple times (until ibus restart ).
Console6.txt (164.4 KB ) - added by JB 9 years ago.
Console8.txt (170.6 KB ) - added by anonymous 9 years ago.
Console9.txt (191.0 KB ) - added by JB 9 years ago.
Console10.txt (162.5 KB ) - added by anonymous 9 years ago.

Download all attachments as: .zip

Change History (109)

comment:1 by anonymous, 9 years ago

I had this problem two times, some days ago. Jumping between windows, suspending laptop and switching CTRL+ALT+Fx didn't help. I must restart josm. I know that CTRL key then working and maybe ALT too. I was using josm-latest, same java version but Ubuntu 14.04.1.

comment:2 by anonymous, 9 years ago

Seems that this bug only happens on Linux - works fine on Windows 7.

comment:3 by asbjorn.syverhuset@…, 9 years ago

Also has this problem in OSX Yosemite. Happens right after I start. Did not have this problem in previous versions.

comment:4 by Don-vip, 9 years ago

Ticket #11247 has been marked as a duplicate of this ticket.

comment:5 by anonymous, 9 years ago

Using Ubuntu 14.04 LTS and happens to me also.

comment:6 by Don-vip, 9 years ago

Ticket #11469 has been marked as a duplicate of this ticket.

comment:7 by Don-vip, 9 years ago

Ticket #11435 has been marked as a duplicate of this ticket.

comment:8 by Don-vip, 9 years ago

Cc: asbjorn.syverhuset@… jbcorbeille-josm@… dieterdreist akks added
Keywords: keyboard input focus added; template_report removed

@akks: there are now several people complaining of keyboard focus on all platforms, do you think it could be a problem of AdvancedKeyPressDetector?

comment:9 by Klumbumbus, 9 years ago

Happens also to me since some months on Win7. Keyboard input always stops, when adding tags window is open. closing this window with the mouse fixes this bug for me and keyboard works again without problems.

Revision: 8419
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-05-23 01:40:23 +0200 (Sat, 23 May 2015)
Build-Date: 2015-05-23 01:31:25
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8419

Identification: JOSM/1.5 (8419 de) Windows 7 32-Bit
Memory Usage: 247 MB / 742 MB (110 MB allocated, but free)
Java version: 1.8.0_45, Oracle Corporation, Java HotSpot(TM) Client VM
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:C:\Program Files\Java\jre1.8.0_45\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,768m, -Djnlpx.splashport=50328, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]

comment:10 by Don-vip, 9 years ago

Milestone: 15.05

comment:11 by Don-vip, 9 years ago

I really can't reproduce I'll need a detailed step-by-step workflow leading to this problem.

comment:12 by JB, 9 years ago

That is part of the problem: even after a few months and probably several dozens times of the problem happening, I still have not been able to find a way of reproducing it.

comment:13 by mdk, 9 years ago

First my guess what could happen: Is it possible that a modal dialog can be closed and keep the focus (or without restoring the KeyEventListener on the parent)? In this case all KeyEvents will be lost.

As I try to remember in which cases the error occurs during my edits, I think it has to do with the "add value" or "change value" dialog and closing the dialog with ESC or ENTER. It always happens, when I accidentally hit more than one key on closing (I think).

I tried to reproduce it during the last hour. I managed to trigger the bug one time with the "add value" and one time with the "change value" dialog. But I wouldn't call it "reproducible".
The steps are something like: Open the dialog, enter or change key and/or value and close dialog with ENTER and ESC at the same time.

I looked into the code and found that ExtendedDialog has a private "result" field, which is set by (asynchronous) KeyEvent handler for ESC and button actions. So I think it would be better to define "result" as "volatile". But I don't think this will explain the total lost of KeyEvents.

in reply to:  13 comment:14 by Don-vip, 9 years ago

Replying to mdk:

So I think it would be better to define "result" as "volatile". But I don't think this will explain the total lost of KeyEvents.

We can already try it :)

comment:15 by Don-vip, 9 years ago

In 8430/josm:

see #11209 - Make ExtendedDialog.result volatile

comment:16 by Don-vip, 9 years ago

In 8441/josm:

see #11209 - add debug messages

comment:17 by Don-vip, 9 years ago

can you please try to reproduce the bug with --debug and post the console output?

comment:18 by anonymous, 9 years ago

Uh, I could try… if you explain the process a bit more?

comment:19 by Don-vip, 9 years ago

java -jar josm-latest.jar --debug

if you're on Windows/OSX you need to enable Java console as explained here: https://www.java.com/en/download/help/javaconsole.xml

comment:20 by anonymous, 9 years ago

Ok, the bug just happened… but I have not found where to find the console output?

comment:21 by akks, 9 years ago

I am here. Will try to do what I can.

Ideas:
1) I doubt the problem is in AdvancedKeyPressDetector because it does not have "consume()" and focus changing. If that additional event handler stop working, only Alt/Ctrl/Shift-clicking and "A" pressing will be affected, not all input (we had the analogous code in drawing mode for years).
2) (offtopic) It would be useful to have automatically created debug output file in --debug mode
3) I have searched a log for last 4 months. Keyboard-related changes are workaroundJdkBug6322854() and .consume in SearchFieldKeyListener

=> intuition says that the bug is related to r8072 or r8081 . It has globally visible newly added .consume() ... However, the .consume in for searchField only. Not sure it can affect other windows and fields.

P.S. Oh, no - searchField can potentially consume only Enter key.

The log or reproducing way is really needed...

Last edited 9 years ago by akks (previous) (diff)

comment:22 by akks, 9 years ago

ImageryAdjustAction is most likely unrelated - did all who reproduce the bug enter image shifting mode?
MenuScroller consumes only mouse wheel events too.

.consume() in SelectAction will work only if "getShortcut().isEvent(e)", so it can not catch other keys.

So my next guess is that .consume() can not be the reason of this bug.

The focusing issues are very hard to track down. But the idea by mdk could be true: we have many .requestFocus() calls.

Question for those who reproduce:
1) Did you open or shift some imagery before editing? (no, most likely)
2) Were really all keys blocked - A, W, Alt- and Ctrl- shortcuts?
3) Clicking on map or switching modes on toolbar did not help? (it requests focus explicitly, even if it is somehow stolen)
4) Did anyone reproduce something like that without "Add tag" dialog?

Last edited 9 years ago by akks (previous) (diff)

comment:23 by JB, 9 years ago

Question for those who reproduce:

Some answers here.

1) Did you open or shift some imagery before editing? (no, most likely)

Open, you mean, like viewing Bing sat ? Yes, at least 2 of them. But no imagerie offset, if that's what you mean with shift?

2) Were really all keys blocked - A, W, Alt- and Ctrl- shortcuts?

On the tag dialog, nothing works. Escape and Entry don't work either.
Closing the tag window with the mouse: shortcuts A (drawing mode) and S (selection mode) do work. Shortcut Alt-A for opening the tag window also works. Tab, esc, ctrl+H, etc… work.
Reopening the tag window, keyboard still does not work, same with in Send dialog.
Mouse to select drawing or selection mode, drawing a few nodes, selecting a few objects changes nothing.

3) Clicking on map or switching modes on toolbar did not help? (it requests focus explicitly, even if it is somehow stolen)

See above. Changes nothing. Let's try lasso mode, changes nothing either.

4) Did anyone reproduce something like that without "Add tag" dialog?

Did not happen to me, but I'm using the send dialog much much less often than the tag dialog! And effects are seen only on those two dialogs (perhaps not only, but I'm not using other dialogs where the keyboard is required).
And let's write it here again, the one CPU core is running at maximum with the java.exe for the time JOSM blocked.

Last edited 9 years ago by Don-vip (previous) (diff)

comment:24 by anonymous, 9 years ago

On Tag dialog, when selecting a key from droplist with the mouse, for example landuse, the value proposals do not load (blank list).

comment:25 by akks, 9 years ago

@JB, @аноним: thank you very much! This may help some of us to figure it out.

So the keyboard becomes broken in dialogs only... And after first bug, all the dialogs are "infected". Very interesting.

Just in case, next time please check that keyboard is not working in other dialogs (relation editor, F3). This may be related to HistoryComboBox only (Search dialog should stop working too, by the way)... Try also TAB and arrow keys.

comment:26 by JB, 9 years ago

Strange one, you may like it. Reproduced 3 times, I think it should be enough. And a workaround for those who are blocked…
F3 dialog: keyboard does not work.
Relation dialog:

  • open relation dialog, don't change anything, close with Entry or Escape (yes, they do work). But keyboard still blocked when opening the tag dialog.
  • open relation dialog, add a new key and/or value: the keyboard does work. Close the relation dialog with entry or escape (dismiss changes), the keyboard works again in tag dialog.

comment:27 by Don-vip, 9 years ago

Ticket #11486 has been marked as a duplicate of this ticket.

comment:28 by Don-vip, 9 years ago

Cc: Atalanttore added

comment:29 by akks, 9 years ago

Very similar bug in Ubuntu: Java+IBus:
https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/481656

JOSM is mentioned several times...

comment:30 by akks, 9 years ago

This is 90% related to input method switching. Try to disable "Use English language for tag by default" in Alt-A dialog context menu. If the bug is gone, it is certainly because of input method.

Last edited 9 years ago by akks (previous) (diff)

comment:31 by JB, 9 years ago

I did not know of this option, and when I looked, it was not checked. So I tryed to change it to « checked », and the bug still happened a few minutes later…

comment:32 by JB, 9 years ago

Ho, I forgot, once the keyboard is blocked, the mouse works fine of the tag dialog, but right clic opens the context dialog, but I'm unable to select any of the lines (for example, unchecking the Use English…).

in reply to:  30 comment:33 by Don-vip, 9 years ago

Replying to akks:

This is 90% related to input method switching.

Interesting bugs:
javabug:6922061
javabug:7155963

comment:34 by akks, 9 years ago

@JB: could you try the workaround http://ubuntuforums.org/showthread.php?t=1612164 next time?
Something like
XMODIFIERS= java -jar josm-latest.jar --debug
And the versions of Java/Linux/window manager/keyboard layout list would be useful :)

Non-working menus: yes, this looks like some deadlock in java gui event queues found by Don-vip...

Last edited 9 years ago by akks (previous) (diff)

comment:35 by JB, 9 years ago

Ok, here is the console output (if I'm not wrong somewhere), the last few thousands lines, I'm not sure how much you needed. I stopped interacting as soon as the tag panel stopped seeing the keyboard.

Some info:

Revision: 8441
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-06-02 14:03:31 +0200 (Tue, 02 Jun 2015)
Build-Date: 2015-06-02 12:06:24
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8441

Identification: JOSM/1.5 (8441 fr) Windows 7 64-Bit
Memory Usage: 208 MB / 247 MB (93 MB allocated, but free)
Java version: 1.8.0_31, Oracle Corporation, Java HotSpot(TM) Client VM
Program arguments: [--debug]
Dataset consistency test: No problems found

Using Windows7, laptop keyboard modified to the « french » BÉPO layout.

Last edited 9 years ago by Don-vip (previous) (diff)

by JB, 9 years ago

Attachment: Console.txt added

Console output, june 3rd, 21h.

in reply to:  35 ; comment:36 by Don-vip, 9 years ago

Replying to JB:

Using Windows7, laptop keyboard modified to the « french » BÉPO layout.

Can you please elaborate on that? How do you do that? Does the problem occur if you switch back to default AZERTY keyboard?

Last edited 9 years ago by Don-vip (previous) (diff)

comment:37 by Don-vip, 9 years ago

In 8463/josm:

see #11209 - switch input method as soon as option selected + detect potential errors and implement fallbacks and logs

in reply to:  36 comment:38 by JB, 9 years ago

Bépo : using the bépo layout driver downloaded there: http://bepo.fr/wiki/Windows. Normal keyboard, but instead of typing E when pressing the third key, it types P instead…
I can try with the standard azerty (the workflow may drop in speed!). With 8463, I suppose?

comment:39 by anonymous, 9 years ago

I have not reproduced the bug this morning, using 8465 and the BÉPO layout. The CPU usage also seems lower (not at the maximum as earlier). If it happens again, I'll let you know.

comment:40 by JB, 9 years ago

I wrote too early. No problem for more than half an hour (much longer than usually), then again. Console log joined. Using 8465 with BÉPO layout.

by JB, 9 years ago

Attachment: Console2.txt added

comment:41 by Don-vip, 9 years ago

Milestone: 15.0515.06

and without bépo drivers?

this subject is definitively not easy, we'll continue in the next release.

comment:42 by akks, 9 years ago

Could you also try updating java to latest 1.8.0_45?
Maybe it is related... (I tried bepo on windows 8.1, latest java 8, noticed no bugs but was not working for long)

comment:43 by JB, 9 years ago

I've updated Java. I've tried a bit in Azerty, no problem (but I am so slow that way…), switched to Bépo, no problem for a rather long while until a complete freeze on the tag dialog. Complete freeze: no keyboard effect, no mouse effect, can't close the dialog with the mouse (cliking on validate/cancel/topright dialog cross). Console log joined.
PS: I actually don't know if it's related to this ticket.

by anonymous, 9 years ago

Attachment: Console3.txt added

comment:44 by JB, 9 years ago

One more info: yes, it is possible to get this problem with the send-data dialog, just happened now. Console4 joined.
Unfroze (with no action from me, it seems) a few seconds/minutes later. Console 5 joined after the unfreezing (and a few actions… sorry, but it seems both files overlap).

by JB, 9 years ago

Attachment: Console4.txt added

by anonymous, 9 years ago

Attachment: Console5.txt added

comment:45 by akks, 9 years ago

@JB: Your log shows clearly that "Use english tags by default" id properties.fix-tag-combobox-locale=true
("Using English input method" in log)

You have no available EN_US locale (or Java thinks so), so something strange happens periodically after activating Alt-A (instead of ignoring language switch).

I did not know of this option, and when I looked, it was not checked. So I tryed to change it to « checked », and the bug still happened a few minutes later…

Could you re-check the option, switch it off and try catching bug without it once more?

Last edited 9 years ago by akks (previous) (diff)

comment:46 by akks, 9 years ago

In 8481/josm:

see #11209: potentially fix input method switching problems

comment:47 by akks, 9 years ago

Sorry for committing too late again, but this change is rather harmless and potentially can solve this nasty bug in tested.

Long long ago in r5704 I have accidentally made inputContext static, so this object was shared by all autocompleting comboboxes. This could cause the problem in certain circumstances.

Last edited 9 years ago by akks (previous) (diff)

comment:48 by Don-vip, 9 years ago

No problem the release isn't out yet we'll include this change and see if it solves the problem :)

comment:49 by JB, 9 years ago

I've edited quite a bit today with 8479, Bépo and "Use english tags by default" unchecked, and got no problem so far. Hope it holds.

comment:50 by Don-vip, 9 years ago

You must wait for r8481+ :)

comment:51 by Don-vip, 9 years ago

Have you been able to reproduce with r8481?

in reply to:  51 comment:52 by JB, 9 years ago

Replying to Don-vip:

Have you been able to reproduce with r8481?

I've only used it a bit… and will not have much time until next week. If anything happens, I'll let you know, but no info does not mean it's ok, only that I've not used it!

comment:53 by alv, 9 years ago

I got the the UI completely stuck with r8481, when I opened the add tag dialog. Only this time it went to not accepting any mouse clicks, either, and I had to kill the JOSM process. This time I was running with --debug but I had to copy from the terminal window (Win 7), so the line breaks are weird in the first log.

The second log is a better formatted excerpt from the next run, where the input was on longer accepted, but it recovered by canceling with the mouse and retrying. (The dialog was in the stuck state when the log has the lines about "Received ENTRY_CREATE event", when I copied the log file to indicate the point where it happened.)

My system has a Finnish keyboard layout, but that setting in the context menu is not set to use English layout for input.

I've been using r8471 for a while, and this has occured much more seldom than it did with the tested 8339 or latest-8413, and the trick with the relation dialog did seem to work, if just closing and reopening the add tag dialog wasn't enough. But not this time (my first log).

The strange thing is that at least once (not this time) I managed to type (very fast) four or five characters into the "key" input, autocomplete even showed the key suggestion, and only then the keyboard input no longer worked. That time, after closing the dialog, keyboard shortcuts did work, like shift+b to distribute nodes, but further add tag dialogs remained unresponsive until I tried the relation dialog trick.

by alv, 9 years ago

Attachment: josm-input-stuck-debug.txt added

totally unresponsive in the end

by alv, 9 years ago

dialog stuck in the middle, then recovered

comment:54 by alv, 9 years ago

If I'm reading the second log correctly, when the ui gets stuck, the "alt+a released" event never happens, i.e. line starting with

DEBUG: AdvancedKeyPressDetector enabled=false => processKeyEvent(java.awt.event.KeyEvent[KEY_RELEASED,keyCode=65,keyText=A,keyChar='a',modifiers=Alt,extModifiers=Alt,keyLocation=KEY_LOCATION_STANDARD, ...

is missing that time, but does exist every other time the add tag dialog is shown. The previous line, and the last line of my first log is as follows:

DEBUG: AdvancedKeyPressDetector enabled=false from org.openstreetmap.josm.gui.tagging.ac.AutoCompletingComboBox$1.focusGained(AutoCompletingComboBox.java:195)

Before that, there's something strange going on, i.e. the last keys before "enter" to close the dialog invoke "released" KeyEvents only after the dialog was already hidden, and the first typed character in the dialog had a superfluous Alt-modifier?

Reading the full log and looking also at the other times the dialog was shown normally, the normal flow is:

  • ProcessKeyEvent key_pressed alt
  • doKeyPressed key_pressed alt (* this line not always present)
  • ProcessKeyEvent key_pressed keyChar='a',modifiers=Alt (aka. "a+alt" from now on)
  • doKeyPressed key_pressed a+alt (* this line not always present)
  • AddTagsDialog.setVisible true
  • processKeyEvent key_typed a+alt (* sometimes after the next line)
  • focusGained
  • processKeyEvent key_released a+alt
  • sometimes also: processKeyEvent key_released alt

Offending flow is (at least in these two cases it was):

  • processKeyEvent key_pressed alt
  • processKeyEvent key_pressed a + alt
  • doKeyPressed key_pressed a + alt
  • AddTagsDialog.setVisible
  • processKeyEvent key_typed a+alt
  • focusGained --> then nothing

comment:55 by mdk, 9 years ago

Bad news first: problem still exists in r8487

And here a good one: I found a way to reproduce the bug in a reliable way:

  1. Select an existing object (like a building)
  2. Open tag edit dialog by double click on a tag (like building=yes) in the "Tags for selected objects" view.
  3. Press RETURN, this triggers the "OK" button of the tag edit dialog.
  4. Press RETURN, this opens the tag edit dialog again. Curiously this dosen't work if you open the tag edit dialog using the keyboard (ALT-S) or using the "Edit" button of the view!
  5. Continue pressing RETURN as fast as you can. This opens and closes the dialog all the time.
  6. When openeing or closing of the dialog stops, than because keyboard input has stopped working. :)

comment:56 by Klumbumbus, 9 years ago

I cannot reproduce it this way.

Also point 4 works fine for me.

comment:57 by mdk, 9 years ago

Perhaps this is a Linux or Ubuntu specific detail. Or I can easily trigger it because I have a very slow CPU. Perhaps you need to slow down your PC.

I can also trigger this with the auto key repeat (just keep ENTER pressed), but it is a little bit to slow, so it takes some seconds.

I think generally the problem is opening a dialog while the dialog before is still closing.

comment:58 by akks, 9 years ago

Can not reproduce on Windows, trying to use Ubuntu in VirtualBox.

@mdk: Could you tell which version of Linux and Java are you using and which desktop environment?

in reply to:  58 comment:59 by mdk, 9 years ago

@mdk: Could you tell which version of Linux and Java are you using and which desktop environment?

Revision: 8487
Repository Root: http://josm.openstreetmap.de/svn
Relative URL: ^/trunk
Last Changed Author: Don-vip
Last Changed Date: 2015-06-11 01:00:43 +0200 (Thu, 11 Jun 2015)
Build-Date: 2015-06-11 01:32:10
URL: http://josm.openstreetmap.de/svn/trunk
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last Changed Rev: 8487

Identification: JOSM/1.5 (8487 en) Linux Ubuntu 15.04
Memory Usage: 242 MB / 878 MB (108 MB allocated, but free)
Java version: 1.8.0_45-internal, Oracle Corporation, OpenJDK Server VM
VM arguments: [-javaagent:/usr/share/java/jayatanaag.jar, -Djosm.restart=true, -Djosm.home=/home/michael/.josm-latest, -Djava.net.useSystemProxies=true]

Plugins:
- ColumbusCSV (31241)
- FastDraw (31241)
- HouseNumberTaggingTool (31241)
- OpeningHoursEditor (31241)
- RoadSigns (31241)
- SimplifyArea (31241)
- buildings_tools (31241)
- contourmerge (1013)
- imagery-xml-bounds (31241)
- imagery_offset_db (31241)
- poly (31241)
- public_transport (31241)
- reltoolbox (31241)
- reverter (31241)
- terracer (31241)
- turnrestrictions (31241)
- utilsplugin2 (31241)

and Standard Unity Desktop.

I also tried it runnung JOSM inside Eclipse with Java 7 instead of Java 8, where I could reproduce the failure the same way (need very fast "hacking" the RETURN key):

Build-Date: 2015-06-13 14:57:02
Revision: 8488
Is-Local-Build: true

Identification: JOSM/1.5 (8488 SVN en) Linux Ubuntu 15.04
Memory Usage: 170 MB / 878 MB (48 MB allocated, but free)
Java version: 1.7.0_79, Oracle Corporation, OpenJDK Server VM
Java package: openjdk-7-jre:i386-7u79-2.5.5-0ubuntu1
VM arguments: [-javaagent:/usr/share/java/jayatanaag.jar, -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:42124, -Dfile.encoding=UTF-8]

Can you give me a hint where to look into the code? Or have you a patch with additional log messages? So I could try to help debugging.

comment:60 by akks, 9 years ago

@mdk: Thank you very much, I have reproduced it too. Have 32bit Ubuntu VM on 64 bit Core Duo (what makes it very slow).
No plugins, no complex layouts, no auto-switching language enabled. No events goes to AWTEventListener after keyboard hanging.

I agree that the origins seems to be in manual focus switching at incorrect moments. Will try to investigate more...

P.S. Too many focusing magic, can not do anything today.

Last edited 9 years ago by akks (previous) (diff)

comment:61 by Don-vip, 9 years ago

See if r8489 helps.

in reply to:  61 comment:62 by akks, 9 years ago

Replying to Don-vip:

See if r8489 helps.

Checked on VM (compiling from svn) - the bug is still reproducible (this time 64 bit VM). By the way, pressing ENTER often opens multiple Alt-S windows

Last edited 9 years ago by akks (previous) (diff)

comment:63 by akks, 9 years ago

The bug on Ubuntu stops showing when IBus is stopped by killall ibus-daemon like there: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/48165
https://bugzilla.redhat.com/show_bug.cgi?id=800736
https://bugzilla.redhat.com/show_bug.cgi?id=1145725

Workaround from those bugreports:
ibus restart
in console unlocks JOSM keyboard!

However, I think some "undefined behavior" with focus or inputmaps in the code may be causing this too (how else the bug can be triggered on Windows?)

Version 0, edited 9 years ago by akks (next)

comment:64 by akks, 9 years ago

Starting JOSM with
XMODIFIERS= java -jar josm-custom.jar
also prevents the bug (just checked) like for other described java apps.

Last edited 9 years ago by akks (previous) (diff)

by akks, 9 years ago

Even after applying this patch I can reproduce the bug on Linux by mdk's method.

by akks, 9 years ago

I tried disabling AdvancedKeyDetector completely and replacing EditTagDialog with simple mock JOptionPane.showInputDialog/ The bug is the same! It is not related to ialog specifics - any frequently opened and closed dialog with text input can hang the keyboard.

by akks, 9 years ago

(I am afraid we cannot do anything to work-around the bug on Linux in JOSM code. Here is the trivial version and with it the keyboard still hangs after pressing Enter in tag table multiple times (until ibus restart ).

comment:65 by alv, 9 years ago

With the latest r8489, on a Win7, in normal editing, the add tag dialog already twice in a row didn't accept any keypresses, but so far I haven't experienced the complete unrecoverable lock up - not that I've used this for long. Btw with the --debug option it did seem to occur more frequently (which isn't unexpected).

comment:66 by Don-vip, 9 years ago

Milestone: 15.0615.07

skip milestone 15.06

comment:67 by JB, 9 years ago

Seems to happen less often these days. Console6.txt log joined. Note that I've been able to very quickly type «na» in the tag window (and «name» has been suggested as key). Also note that when I switched to the console, many lines were still being written.

by JB, 9 years ago

Attachment: Console6.txt added

comment:68 by JB, 9 years ago

Actually, it is not exactly the same, as the tag panel does not respond to mouse interaction: no closing/validating. Forced JOSM closing.

comment:69 by JB, 9 years ago

Happened a second time, but this time, I was able to close the panel with the mouse. JOSM was seemingly slower before it happend. I was able to recover the keyboard use by using the relation panel. console7.txt joined.

comment:70 by JB, 9 years ago

I don't know if you need more console log, here is one: console8.txt (if not recognized as spam, at least…)

by anonymous, 9 years ago

Attachment: Console8.txt added

comment:71 by akks, 9 years ago

In r8537 I have added option debug.advanced-keypress-detector.enable

@JB: Could you try to catch the bug with debug.advanced-keypress-detector.enable=false next time?
When debug.advanced-keypress-detector.enable=false , angle snapping, box/lasso switching from keyboard will be disabled and Alt/Ctrl detection in different modes could be slighly broken, but JOSM should be mostly usable.

If the bug will not happen, then AdvancedKeyPressDetector is most likely related.

in reply to:  71 ; comment:72 by JB, 9 years ago

@akks: please note that I'm no specialist… Do I have to do anything except wait for next latest and play around with it?

in reply to:  72 comment:73 by akks, 9 years ago

Replying to JB:

@akks: please note that I'm no specialist… Do I have to do anything except wait for next latest and play around with it?

Yes, please check if you could catch the bug in next latest. Change debug.advanced-keypress-detector.enable manually to false in advanced preferences (F12-last tab) before opening the map.

comment:74 by akks, 9 years ago

In 8538/josm:

some more debugging output, see #11209

comment:75 by JB, 9 years ago

Got it. Console9.txt joined. Could unlock it using the relation panel trick.

by JB, 9 years ago

Attachment: Console9.txt added

comment:76 by JB, 9 years ago

And another one, worked again quite fast with no action from my part (I think). Console10.txt.

by anonymous, 9 years ago

Attachment: Console10.txt added

comment:77 by mmyfl, 9 years ago

I've found something even more interesting:

  • Open JOSM.
  • Use mdk's method --> input gets stuck.
  • Now make sure you are in the tag edit dialog, restart ibus.
  • Close the tag edit dialog (OK or Cancel or other ways) --> crash.

comment:78 by mdk, 9 years ago

Thanks mmyfl!

To be more precise: The JVM is craching:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x628afc40, pid=4816, tid=1678502720
#
# JRE version: OpenJDK Runtime Environment (8.0_45-b14) (build 1.8.0_45-internal-b14)
# Java VM: OpenJDK Server VM (25.45-b02 mixed mode linux-x86 )
# Problematic frame:
# C 0x628afc40

But I think this is not relataed to our Problem. Simplified way to reproduce:

  1. Open JOSM
  2. Open tag edit dialog
  3. restart ibus
  4. close tag edit dialog --> core dump

I think the ibus restart invalidates some resources which are accessed on closing the dialog and cause the segment fault.

comment:79 by mdk, 9 years ago

BTW: Does anybody else has the effect, that the keyboard layout changes after "ibus restart"? I use Ubuntu and have normally german keyboard, but after "ibus restart" I have englich layout, although the keyboard indicater still shows "De". The wrong keyboard layout (on startup) is also an old Ubuntu issue.

Do we have 3 different problems all related to ibus?

  • ibus blocks keyboard input in Java application
  • ibus restart cause segment fault in JVM
  • ibus restart change keyboar layout to us-english

comment:80 by Don-vip, 9 years ago

Milestone: 15.0715.08

Milestone renamed

comment:81 by Don-vip, 9 years ago

Milestone: 15.0815.09

comment:82 by simon04, 9 years ago

Component: Core
Milestone: 15.0915.10

Postpone to 15.10

comment:83 by Don-vip, 8 years ago

Milestone: 15.1015.11

comment:84 by Don-vip, 8 years ago

Ticket #12017 has been marked as a duplicate of this ticket.

comment:85 by skquinn, 8 years ago

Component: Applet

Me too. Ubuntu 14.04, upgraded from 10.04 and 12.04 if that matters, latest Java I can get. Seems to be rather random; I am able to copy and paste (I often use a terminal running 'cat >/dev/null') to upload/save until I can restart JOSM.

comment:86 by Don-vip, 8 years ago

Milestone: 15.1115.12

comment:87 by Don-vip, 8 years ago

Component: AppletCore
Keywords: linux ibus javabug added

comment:88 by mdk, 8 years ago

Good news!
After updating Java to openjdk-7-jre:i386-7u91-2.6.3-0ubuntu0.15.10.1 I couldn't reproduce the problem any more.

I tested it like described above:

  • download data
  • select an object and open "Add value?" dialog
  • press down RETURN key and don't release (for the next minutes)

With the new Java7 version the keyboard input doesn’t stop!

But two observations:

  1. Normally the dialog opens and close all the time. But after about 1 minute the behavior change: Instead of closing the dialog, JOSM only opens new dialogs. Within a few seconds I got 50 to 100 "Add value?" dialogs. But you can close all of them without other side effects.
  2. I thought the default JVM is now Java 8 (#11390), but actually josm-latest (9062) and also the stable version (9060) starts with Java 7.

With Java 1.8.0_66-internal neither the keyboard input stops nor multiple dialogs are opened.

comment:89 by Don-vip, 8 years ago

In 9084/josm:

see #11209 - change log messages level from debug to trace

comment:90 by Don-vip, 8 years ago

Milestone: 15.12
Resolution: othersoftware
Status: newclosed

comment:91 by Don-vip, 8 years ago

In 9085/josm:

see #11209 - change log messages level from debug to trace

comment:92 by Lachgast, 3 years ago

This error pops up, five years later.
The error occurs both with the most recent version and the current stable version.
It seems to be happening since I updated Ubuntu Studio to Groovy Gorilla. This runs on Plasma, a version op Kubuntu, based on KDE.

comment:93 by JB_, 3 years ago

It never really disappeard for me. With the background, I guess it happens more often when JOSM is under heavy load (lots of data) and fast workflow (keyboard shortcuts). I now use the «relation dialog stunt» (https://josm.openstreetmap.de/ticket/11209#comment:26) to get it working again.

comment:94 by anonymous, 3 years ago

I have run into the same issue - after editing a relation, keyboard input ceases to work in JOSM (v17833, java:11.0.11)

comment:95 by mkoniecz, 16 months ago

For me it stopped appearing since I got rid of ibus.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.