#137 crash using btn2 on help window buttons

release
closed-fixed
Program (402)
7
2003-06-21
2002-03-07
No

Current nedit version crashes (exit value 1) whenever I
use Mouse button2 to click one of the four buttons
(Find..., ...) of the help window.

Version info: (unmodified cvs head as of 2002/03/05)

NEdit release of Mar 6, 2002

Built on: Solaris, Sparc, GNU C
Built at: Mar 7 2002, 15:57:25
With Motif: 2001 [@(#)Motif Version 2.1.0]
Running Motif: 2001
Server: Sun Microsystems, Inc. 3610

Error Message:
X Error of failed request: BadMatch (invalid parameter
attributes)
Major opcode of failed request: 1 (X_CreateWindow)
Serial number of failed request: 4721
Current serial number in output stream: 4723

gdb says there is no stack trace! (Yes, it's compiled
with -g).

Markus Schwarzenberg

Discussion

  • Markus Schwarzenberg

    Logged In: YES
    user_id=81393

    On Mar 7, 17:08, Alexander Mai wrote:
    > No stack trace?
    > Well, it should be possible to get one.
    > Please check http://www.lesstif.org/bugs.html
    > and the two external links which it has.

    Thanks for this hint: Now I added an error handling function
    and put a breakpoint there, so now we have a stack trace
    (program compiled whith -g and without -O and run
    -synchronous):

    #0 MyErrorHandler (EDisplay=0x1a0190, Error=0xffbecd78) at
    nedit.c:84
    #1 0xfefa288c in _XError ()
    #2 0xfef94c74 in _XReply ()
    #3 0xfef99bd0 in XSync ()
    #4 0xfefabf78 in _XSyncFunction ()
    #5 0xfef998e0 in XCreateWindow ()
    #6 0xff0b76a0 in XtCreateWindow ()
    #7 0xff0a8b94 in RealizeWidget ()
    #8 0xff0a8934 in XtRealizeWidget ()
    #9 0xff1cb004 in DragContextInitialize ()
    #10 0xff0a6588 in CallInitialize ()
    #11 0xff0a2920 in xtCreate ()
    #12 0xff0aac98 in _XtCreateWidget ()
    #13 0xff0aa9c8 in XtCreateWidget ()
    #14 0xff1ce9e0 in XmDragStart ()
    #15 0xff2757fc in XmeDragSource ()
    #16 0xff1e7720 in ProcessDrag ()
    #17 0xff0bf148 in HandleActions ()
    #18 0xff0bdf68 in HandleSimpleState ()
    #19 0xff0bda40 in _XtTranslateEvent ()
    #20 0xff0bd974 in XtDispatchEventToWidget ()
    #21 0xff0bd200 in _XtDefaultDispatcher ()
    #22 0xff0bcd28 in XtDispatchEvent ()
    #23 0xff0ba93c in XtAppMainLoop ()
    #24 0x1c0f8 in main (argc=1, argv=0xffbee534) at nedit.c:532

    BTW, the error handling function is:

    int MyErrorHandler( Display *EDisplay, XErrorEvent *Error)
    { char ErrMsg[80];

    XGetErrorText(EDisplay, Error->error_code, ErrMsg, 80);
    fprintf(stderr, "Error detected:\n %s\n", ErrMsg);
    fprintf(stderr, " Protocol request: %d\n",
    Error->request_code);
    fprintf(stderr, " Resource ID: 0x%x\n",
    Error->resourceid);
    fprintf(stderr, "\nCleaning up and exiting...\n");
    exit(1);
    }

    and reported:

    Error detected:
    BadMatch (invalid parameter attributes)
    Protocol request: 1
    Resource ID: 0xa400007

    Markus Schwarzenberg

     
  • Eddy De Greef

    Eddy De Greef - 2002-03-07

    Logged In: YES
    user_id=73597

    It doesn't look like NEdit has anything to do with it.
    Something seems to go wrong when Motif is trying to create
    a drag icon.
    It is possible that something got corrupted before the
    button press, though.

     
  • Markus Schwarzenberg

    Logged In: YES
    user_id=81393

    On Mar 8, 0:08, Alexander Mai wrote:
    > Subject: Re: [ nedit-Bugs-526981 ] crash using btn2 on
    help window buttons
    ...

    > Anyway, from my point of view it looks like a bug
    > in OM, not only due the (almost) "nedit free" call stack.
    > LessTif is also happy with Btn2, at least it doesn't crash
    :-)

    ... It's not OM ;-) (OM works (linux)). It's SUN Motif. It
    crashes only with the libXm.so.4 (@(#)Motif Version 2.1.0)
    linked, not for libXm.so.3 (@(#)OSF/Motif Version 1.2.6). A
    workaround would be to remove all the actions bound by
    default to <btn2> for all dialog buttons (we never drag
    something on buttons ...).
    BTW, it crashes not only for the help window buttons, but
    apparantly for all dialog buttons (!!!).

    (Maybe there is some highly importand patch missing on our
    SUNs ???)

    Markus Schwarzenberg

     
  • Markus Schwarzenberg

    Logged In: YES
    user_id=81393

    Could someone running nedit on a sun/sunos5.7 please check
    what happens when an existing selection inside one of the
    nedit dialogs (for example the find dialog) is *dragged*
    using mouse button 2? (just to move this selction some
    characters)

    I get exactly the same crash and stack trace as below, so it
    seems the problem exists not only for the help window!!

    I disabelt all my own ~/.Xdefaults $XAPP/NEdit and made
    shure nedit was compiled with the latest sun-patches headers
    and linked to their latest X11/Xm libraries before when I
    tested it.

    Looking at the stack trace it looks like a motif problem -
    but the same problem doesn't exist for other (self compiled)
    motif applications (for example xephem - draging works
    perfectly there / xmgrace - dragging is disabelt there by
    default (fallback resource) but works when it's enabelt
    again) - somehow the crash must really be nedit-related

    BTW1: the crash doesn't happen with linux/openmotif
    BTW2: the crash can be avoided by setting the resource:
    nedit*dragInitiatorProtocolStyle: XmDRAG_NONE

    Hah! It doesn't crash when the resource nedit.visualID is
    set to PseudoColor. For all other visuals it crashes.

    Markus Schwarzenberg

     
  • Eddy De Greef

    Eddy De Greef - 2003-05-05
    • labels: --> Program
    • milestone: --> release
     
  • Eddy De Greef

    Eddy De Greef - 2003-05-05

    Logged In: YES
    user_id=73597

    This is almost certainly a Motif bug.
    I can reproduce it with OpenMotif too, provided that I start
    NEdit with a non-default visual. It is very similar to #602260.
    Hitting a dialog button (or dragable selections) with mouse
    button 2 triggers a drag icon drawn in a popup shell. For
    the popup shells that we create ourselves in NEdit, we
    carefully set the visual, color map, and depth.
    OpenMotif doesn't do this (I've checked the source) and I
    guess the same happens in the official Motif, which causes
    the crashes.
    Lesstif, on the other hand, explicitly installs the default
    visual, color map, and depth, and has no problem.

    AFAIK, there is nothing we can do about this, except disabling
    this kind of dragging when we are not using the default visual.
    Anyone else got a better idea ?

     
  • Scott Tringali

    Scott Tringali - 2003-05-05

    Logged In: YES
    user_id=11321

    Here's an idea. Instead of manually wrapping each shell
    creating feature, how about we stuff the resource database
    with the (visual, colormap, depth) triple? I think this
    would have two benefits:

    1) It would cover the cases when Motif creates a shell on
    our behalf, as in this bug.
    2) If would remove the need for all the shell creation
    wrappers, and be less error-prone

     
  • Eddy De Greef

    Eddy De Greef - 2003-05-05

    Logged In: YES
    user_id=73597

    I have already spent a few evenings trying that, but I
    didn't succeed.
    I'm not saying that it is impossible, it is probably just my
    lack of knowledge on these things (and the fact that it is
    very hard to debug crashes somewhere deep down in X, without
    having the source).
    But it would definitely be a lot cleaner than what we have now.

     
  • Scott Tringali

    Scott Tringali - 2003-05-23
    • priority: 5 --> 7
    • assigned_to: nobody --> tringali
    • status: open --> open-fixed
     
  • Scott Tringali

    Scott Tringali - 2003-05-23

    Logged In: YES
    user_id=11321

    Fix committed. Sadly, the workaround is the disable widget
    drags entirely when: we're using a non-default visual AND
    it's not LessTif. Power users can override this with a
    resource if they want to live dangerously.

    A little research on Google groups confirms this is a Motif
    bug.

     
  • Scott Tringali

    Scott Tringali - 2003-06-21

    Logged In: YES
    user_id=11321

    In the release notes for 5.4. Markus, please let us know if
    this doesn't solve your problem.

     
  • Scott Tringali

    Scott Tringali - 2003-06-21
    • status: open-fixed --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks