#153 crash using 5.2 on HPUX via Exceed

release
open
nobody
Program (402)
5
2002-04-24
2002-04-24
Anonymous
No

while closing windows:

0 XtSetKeyboardFocus@libXt.2 + 0x00000040
(0x4017bbb8, 0, 0x1, 0x7afbef1a)
1 FocusDestroyCallback@libXt.2 + 0x0000001c
(0x7afcdb88, 0x7afea948, 0, 0)
2 XtCallCallbackList@libXt.2 + 0x00000094 (0,
0x7afea948, 0, 0)
3 Phase2Callbacks@libXt.2 + 0x00000020 (0, 0x1, 0,
0x401a8978)
4 Recursive@libXt.2 + 0x000000b4 (0x2, 0x80031f, 0,
0x401b24c0)
5 Recursive@libXt.2 + 0x0000004c (0, 0x1, 0, 0)
6 Recursive@libXt.2 + 0x0000004c (0x7b03b41c, 0, 0,
0x4017c6f8)
7 Recursive@libXt.2 + 0x0000008c (0x33802200,
0x400ab714, 0, 0x1)
8 Recursive@libXt.2 + 0x0000008c (0x7b03b2d4,
0x7b03b284, 0, 0x40102e08)
9 Recursive@libXt.2 + 0x0000004c (0x800325,
0x40106d78, 0, 0xc)
10 Recursive@libXt.2 + 0x0000004c (0, 0, 0x401c5d90,
0x40065eaa)
11 XtPhase2Destroy@libXt.2 + 0x00000230 (0,
0x400b2324, 0, 0)
12 _XtDoPhase2Destroy@libXt.2 + 0x00000080 (0, 0, 0,
0x1)
13 XtDispatchEvent@libXt.2 + 0x00000160 (0x73612f62,
0x64726577, 0x400b0200, 0x7afe6f4a)
14 ServerMainLoop + 0x000000cc (0x400b0198, 0,
0x40003060, 0x40003068)
15 __iob + 0x00000230 (0x4, 0x7b03a5cc, 0, 0)

Discussion

  • Eddy De Greef
    Eddy De Greef
    2002-04-24

    Logged In: YES
    user_id=73597

    Does it happen when you close 1 window, or only
    when you exit (and close all windows) ?
    Is it reproducable ?

     
  • Logged In: NO

    I was closing the windows individually (probably via Alt+F4)

    First time it's happenned, so I can't claim that it's
    reproducible.

     
  • Steve LoBasso
    Steve LoBasso
    2002-05-01

    Logged In: YES
    user_id=140805

    It seems very reproducible.

    Start nedit.
    Create 10 - 15 empty windows with no unsaved changes.
    Put all the windows on top of each other except one.
    Now hold Alt-F4 down over the pile of windows.
    Depending on your key repeat rate settings it should crash
    on an HP. You will know this since the window that wasn't in
    the pile shouldn't have closed. Occasionally there is an error:

    X connection to rachel:0.0 broken (explicit kill or server
    shutdown).

    This could be some sort or re-entrancy problem. It also
    seems that if there are unsaved changes in a file, it's
    possible to get several "Save file before closing?" dialogs.

     
  • Logged In: NO

    This bug (or maybe its relative) can be reproduced on HP 10.20 without
    the need to open a whole pile of Nedit windows and without Exceed.

    Open a file on an HP desktop and make some keystrokes to modify the text.
    Now hold Alt-F4 for a while and watch what is happenning:

    Depending on the keyboard autorepeat speed, the standard "Save file
    before closing?" dialog appears and disappears. After a short while
    Alt-F4 does not make the window manager to send the kill signal to the
    application; instead, Alt-F4 is accepted by the root window as plain F4,
    and the dialog does not disappear anymore.

    My file ${HOME}/.dt/dtwmrc contains the following entry in Key Bindings
    Description:

    Keys DtKeyBindings
    {
    ...
    <Key>F4 root f.goto_workspace DMSPL
    ...
    }

    So, the window manager throws me at the workspace DMSPL from the current
    one, and the Nedit's window shows up there with the same "Save file ..."
    dialog. Keeping Alt-F4 held down kills any other application under the
    cursor in DMSPL, but Nedit heroically stands on its place.

    This could be either CDE's or Motif's bug, not just Nedit's.

    Some details for reference:

    NEdit release of Apr 12, 2002

    Built on: HP/UX, PA-RISC, GNU C
    Built at: Apr 29 2002, 08:17:10
    With Motif: 1002 [@(#)OSF/Motif Version 1.2.5]
    Running Motif: 1002
    Server: Hewlett-Packard Company 600000

    % xset q
    Keyboard Control:
    auto repeat: on key click percent: 0 LED mask: 00000000
    auto repeating keys: fffffff3fbffffff
    fbfffffff9ffffff
    ffffffffffffffff
    ffffffffffffffff
    ...

    % uname -a
    HP-UX tntsh033 B.10.20 A 9000/778 2016550615 two-user license

    % what `which X`
    /usr/bin/X11/X:
    Built for: 10.20.ace on HP-UX Daily, -O +Onolimit
    X Window System, Version 11 R6
    (build date: Wed Feb 3 09:32:08 MST 1999)

    Regards,
    Yury Burkatovsky

     
  • Eddy De Greef
    Eddy De Greef
    2002-05-02

    Logged In: YES
    user_id=73597

    I can reproduce the sudden exit that Steve describes too,
    even on Linux.
    I never get a core dump, though. One of the X routines
    just calls exit(). When I set a breakpoint, I get this
    stack trace (on HP-UX):

    #0 0x7af4d48c in exit () from /usr/lib/libc.1
    #1 0x7ae4e85c in _XDefaultIOError () from
    /usr/lib/X11R5/libX11.1
    #2 0x7ae4f088 in _XIOError () from /usr/lib/X11R5/libX11.1
    #3 0x7ae4ccd4 in _XRead () from /usr/lib/X11R5/libX11.1
    #4 0x7ae4c7d4 in _XEventsQueued () from /usr/lib/X11R5/libX11.1
    #5 0x7ae3ed94 in XEventsQueued () from /usr/lib/X11R5/libX11.1
    #6 0x7add8e00 in _XtwaitForSomething () from
    /usr/lib/X11R5/libXt.1
    #7 0x7add9d60 in XtAppNextEvent () from /usr/lib/X11R5/libXt.1
    #8 0x85de4 in ServerMainLoop (context=0x400bf908) at
    server.c:150
    #9 0xd934 in main (argc=2, argv=0x7b03a648) at nedit.c:524

    I don't know whether anyone can make any sense out of this,
    but both stack traces make me suspect that it's a problem
    in one of the X/Motif libraries.

    This certainly isn't a recently introduced bug.
    Now I remember having looked at this a long time
    ago already.

    (Yury: Motif keybindings ignore modifiers unless
    explicitly specified, so your Dt keybinding probably
    doesn't consider the state of the Alt key. You can
    try ~Alt ~Shift ~Ctrl ~Meta <Key> F4
    or None <Key> F4
    to make sure that Alt-F4 doesn't get interpreted as F4
    by the root window. The latter form also covers NumLock
    etc., so you probably want the former.)

     
  • Logged In: NO

    Thanks for the tip.

    I have tried your both recommendations: ~Alt ~Shift ~Ctrl
    ~Meta <Key> F4 and None <Key> F4. The result is the same:
    the window jumps to the DMSPL work space and the dialog
    keeps showing up there. (I restarted the window manager
    after every setting change.)

    At any rate, I believe the root window should not accept a
    keystroke while an application (i.e. Nedit) window is active
    - the cursor is always above Nedit and the default
    preference "Popup under Pointer" is set.

    It is very likely that the bug is the manager's fault and
    Nedit has nothing to do with it.

    Regards,
    Yury Burkatovsky