text entry widgets freeze after ~30 minutes

[prjemian]

Two reports of this problem:

Nicholas P. DiMonte:

I have been creating new displays this shutdown and have experienced that medm will stop accepting input from the keyboard, yet the mouse is still functional. This problem appears to happen within 20-30 minutes of when I start editing a display. I have to exit medm and restart it to continue with my edits.

Kevin Peterson

The MEDM freeze happened again on 32idcws.

Here's what I did:

1. I rebooted 32idcws and then logged in as the user account (usr32idc).
2. I started MEDM using their start script (start_epics)
3. I opened dozen MEDM screensn, including one motorx_all.adl
4. I spent five minutes changing values on the motorx_all.adl screen, and all the changes were successful.
5. I gave up trying to reproduce the problem and ssh'ed into other linux machines to do more productive things.
6. I returned to MEDM (25 minutes after launching it) and found that I could no longer enter any text into motorx_all.adl. I can open new related displays. Buttons and menus still work, but I can't enter text on any text-entry fields (on both the adls that were open originally AND new ones that I open since MEDM froze).

I confirmed that my copy of MEDM was the only one that was running on the system. I think you should be able to reproduce the problem by simply opening a medm screen with a text-entry field and letting it run in the background for a while. I don't believe there was anything I did to cause MEDM to freeze.

[prjemian]

Reporting as issue here after email discussions. Here is one email thread:

Hi Guys,

The issue of text entry widgets freezing after the screen has been open
for ~30 minutes has already been reported by BCDA on the beamlines, so
I'm cross-posting to them. The behaviour where related displays no
longer close their parents is due to new version I installed this week
as a workaround for a crash that was also occurring with RHEL7 displays
when they did that. Bob Soliday was only able to prevent that crash by
disabling the "close parent" behaviour. If you really want the old
version and behaviour back you can run medm.00026 on phoebus Linux
clients, medm.00016 on helios Linux clients or medm.00036 on chiron.

Bob, Pete — we should probably be recording these problems in public as
Github issues against the MEDM git repository at
https://github.com/epics-extensions/medm so that anyone can see that
we're at least aware of them.

Controls — this might be a reason to more seriously consider moving the
MCR to running caQtDm (ask Jim Stevens for a demo).

- Andrew

> On 05/18/2017 09:46 AM, Pietryla, Anthony F. wrote:
>> I have the same issues as Marty.
>>
>> I also noticed yesterday that related display button that used to
>> remove the parent, no longer does.
>>
>> Tony

On 05/18/2017 09:14 AM, Martin L. Smith wrote:
> I have not seen this when editing but I am currently having an issue where
> I cannot enter a number into a field but a caput works fine and other
> button
> controls on the display work with mouse clicks ... just not text entry
> fields.
>
> Marty
>
> On 05/18/2017 08:59 AM, Nicholas P. DiMonte wrote:
>> All,
>>
>> I have been creating new displays this shutdown and have experienced
>> that medm
>> will stop accepting input from the keyboard, yet the mouse is still
>> functional.
>> This problem appears to happen within 20-30 minutes of when I start
>> editing a
>> display. I have to exit medm and restart it to continue with my edits.
>>
>> I am going through voltctl while making my edits so I'm not sure if
>> this has
>> anything to do with it or not.
>>
>> Anyone else seeing something similar?
>>
>> Nicholas

[MarkRivers]

Can you please clarify what you think has caused these problems to begin to appear?

• Is it an upgrade to a new OS (e.g. RHEL 7)?
• Is it an upgrade to a new version of medm?

I have been running on RHEL 7 (actually Centos 7) for several months and have not seen these problems. However, I am running medm on a Centos 7 but generally displaying on a Windows machine running MobaXTerm. The fact that I don't see the problem suggests that the problem may be in the X server and not in the medm X client.

[rtsoliday]

I have a reproducible SIGSEGV that I have been testing things with. Screen1 is replaced by Screen2 which then opens Screen3. If Screen3 is closed, the MEDM session SIGSEGVs. This is on RHEL7 with motif-2.3.4-8.el7.x86_64 and not building MEDM with the -DNO_REPLACE_DISPLAY option. I also tried motif-2.3.4-8.1.el7_3.x86_64 and got the same problem.

I can "fix" it by downgrading motif to motif-2.3.4-7.el7.x86_64. I would suggest moving all our RHEL7 computers to this version of motif and seeing if the other problems disappear. Obviously I would like to properly fix medm but this might be good enough for now.

[rtsoliday]

I was slightly incorrect. motif-2.3.4-8.1.el7_3.x86_64 is the only one that is causing problems. motif-2.3.4-8.el7.x86_64 appears to be working fine.