Slickedit result in System halt?

[davidlee62]

I use SE v 11.0 for Linux. My OS is SUSE Linux 10.0 with KDE 3.4.  I find a strange behavior  when using SE to edit the source: if click an area which is lower of the cut icon , the cursor will change to an arrow with a break window, then the whole OS will halt, because the interface cannot accept any key input. Please advise if this is a bug?


David

[trulyliu]

I have the same problem,
I use Fedora 5, Gome 2.14.3
SlickEdit V11.02 with newest hotfixes.
Is it a bug?

This problem troubled me a long time.

[ScottW, VP of Dev]

I'm not aware of any features in SlickEdit that intentionally cause the system to halt, so I'd have to say this is a bug.   

I don't think I understand the circumstances that are causing this, though. Can you provide some more details on what you did that leads to this problem?  Thanks.

--Scott

[Kohei]

When your system "locks up", is the X process racing to 100%, or is it totally locked up?  When that happens, please try to switch to a console screen by holding Ctrl+Alt+F1 (you may have to hold the keys long enough (~10 seconds) if indeed the X is racing).  If that doesn't help, can you still log in remotely into your box via ssh and run 'top'?

Thanks,
Kohei

[trulyliu]

Perhaps my expression is the wrong.
System died away when I clicked on dock toolbar under cut icon when the toolbar was not on focus,
System was not really halted, but it could not response keyboard input and mouse click input,
even if CTRL+ALT+BACKSPACE or CRTL+SHIFT+F1 was invalidation.
mouse motion could be dealed with.
CTRL+ALT+DEL is available.

I telneted to this system from another PC,
I typed command 'kill -9 `pidof vs`
VS was killed, and every thing went well.

[Kohei]

@trulyliu

Thanks.  That confirms my speculation; something in SlickEdit UI code causes X's racing condition.  We'll look into that and see if we can come up with a reproducible case.

Kohei

[livingintown]

I was mad for this question for a quite long time, but I find the possible cause, and solution. In my system, this slickedit v11 is conflict with any non-english input method using XIM. To verify whether you are in the same situation is very simple, kill all non-english input method (Chinese input program, etc), then try slickedit v11.

If so, it seems slickedit v11 has problem to work with XIM backend, switch to another non-english input method won't solve this question, because most of non-english input method do use XIM as backend.

Try to solve this by using following ways:

export GTK_IM_MODULE=
export XMODIFIERS=
/opt/slickedit11/bin/vs

[Kohei]

@livingintown

I'm not sure that's the same problem that the original poster stated.  Your problem is probably related to use of SCIM as the input method backend via XIM (XIM is just a protocol).  What's your value of XMODIFIERS?  Is it set to @im=SCIM?

The workaround for this particular problem of yours is what you already have done, although you don't have to nuke the GTK_IM_MODULE environment variable in this case as we don't use GTK.  Of course, this is just an interim workaround, and we're going to look into finding a more permanent solution for this.

Kohei

[livingintown]

I am not using SCIM, but using fcitx, both are using XIM as a backend. Before I clear those variables, I got same issue. Slickedit 11 just hang the whole system. GTK_IM_MODULE won't work, I tried it first when I start to aware, that slickedit 11 may have problem to work with scim or fcitx.

Both scim and fcitx depend on XMODIFIERS, I clean this variable too, and every thing is fine.

Slickedit 10 didn't have this problem, it seems only slickedit 11. Hope you can find root cause of that.

[davidlee62]

Hi livingintown,

Please advise where to insert the two export sentences? Thanks.


David

[Kohei]

@livingintown:

Just a little update.  I've done some research on this problem, and it appears to be related to a bug in X.org in its handling of synchronous message from an input method.  This is not specific to SCIM, but SCIM manifests this problem rather reproducibly and it happens to be the default input method in many recent distros.

What happens is, when SlickEdit switches keyboard focus from one edit window to another by using key stroke (such as keyboard shortcut or simply hitting the escape key to activate the command line box), SE switches focus of the input context, which triggers the input method to send a message with synchronous reply request to the X-server.  But the X-server never sends a reply back to the input method, thus the input method will stop releasing all future key press events to the client application (SlickEdit) while waiting for the synchronous reply.  So, SlickEdit never receives any more key press events from this point on even though the user is hitting the keyboard repeatedly.

All we are doing internally is to switch input context focus from one edit control to another, and this is enough to confuse the X-server.

There has been many reports of this problem that affects not only SlickEdit but also many other applications:

http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg273947.html
https://bugs.launchpad.net/distros/ubuntu/+source/scim/+bug/66104
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201284

So, at this point, I'm trying to see whether or not there is anything we could do on SlickEdit side to mitigate this problem.  But I can tell you up front that, since we don't receive any key press events from the X-server whatsoever, it's going to be a little difficult to put a workaround for this (other than disabling the XIM support altogether).  So, I'm still having to decide what the "right fix" would be...

@davidlee62

You could create a little wrapper script and launch SlickEdit (the 'vs' binary) by running that script.  For instance, the following script works for me:

Code: [Select]

#!/bin/bash

# Change this path to your own 'vs' location.
VSEXEC=/opt/slickedit/bin/vs
unset XMODIFIERS
$VSEXEC $@

Name this script 'vs' (this is important, otherwise the background search will not run (fixed in v.12) ), and run it instead of the real 'vs' binary.  That should do the trick.

Kohei

[davidlee62]

Thank you Kohei for your reply!  I'll try it . Wish SE have an good future.

David

[trulyliu]

@livingintown:


@davidlee62

You could create a little wrapper script and launch SlickEdit (the 'vs' binary) by running that script.  For instance, the following script works for me:

Code: [Select]

#!/bin/bash

# Change this path to your own 'vs' location.
VSEXEC=/opt/slickedit/bin/vs
unset XMODIFIERS
$VSEXEC $@

Name this script 'vs' (this is important, otherwise the background search will not run (fixed in v.12) ), and run it instead of the real 'vs' binary.  That should do the trick.

Kohei

I have test this scripte. But it seems no use.

[davidlee62]

I have test the script, it can match my environment， so far, not find rejecting keys typing.


David 

[Kohei]

@trulyliu

I have test this scripte. But it seems no use.

You may be experiencing a whole separate issue.  I believe there are two separate problems we are observing in this thread (one related to key stroke loss via XIM and one related to mouse cursor handling), and my script resolves only one of them.  We'll look into the other problem soon-ish.

Kohei