Thread: [Nedit-develop] Re: seg fault with tear-off menus
Brought to you by:
tringali
From: Scott J. T. <sco...@et...> - 2004-01-07 13:40:28
|
Folks, If you head over to http://sourceforge.net/mail/?group_id=11005 you can subscribe to the mailing list there. Then send mail to ned...@li...... |
From: Joerg F. <jf...@gm...> - 2004-01-07 16:21:32
|
>I caught a seg fault with CVS head revision when linked to >OM-2.1.30, and later traced it back to the changes on widget >hierarchy of top-level application shell. Lesstif appeared to be >okay. With lesstif it is ok. But there seems something to be terrible wrong with the latest buffermode fixes. Now all my macros are executed in the first buffer, when I hit the definedeshort-cuts for them.=20 Macro menu entry with insert_string("Ooops") bound to Ctrl-D Open two windows, select the second one, hit Ctrl-D. Then the Ooops is in the first window.=20 Cheers, J=F6rg |
From: TK S. <tee...@ya...> - 2004-01-08 01:00:53
|
--- Joerg Fischer <jf...@gm...> wrote: > >I caught a seg fault with CVS head revision when linked to > >OM-2.1.30, and later traced it back to the changes on widget > >hierarchy of top-level application shell. Lesstif appeared to be > >okay. > > With lesstif it is ok. But there seems something to be terrible > wrong with the latest buffermode fixes. Now all my macros are > executed in the first buffer, when I hit the definedeshort-cuts for > them. > > Macro menu entry with insert_string("Ooops") bound to Ctrl-D > Open two windows, select the second one, hit Ctrl-D. Then the Ooops > is in the first window. I'll take a look, but let's try not to mix up between the two. Besides, the segfault to me is a much bigger problem. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Scott J. T. <sco...@et...> - 2004-01-08 14:37:40
|
TK Soh wrote: > I'll take a look, but let's try not to mix up between the two. Besides, the > segfault to me is a much bigger problem. I'll look at the segfault, since I probably introduced it. Weird, only happens on OpenMotif 2.1, though. Also, folks, sign up for the mailing lists on SF - I have to manually approve any postings that are not from a subscribed address... |
From: Eddy De G. <de...@im...> - 2004-01-08 14:49:28
|
On 2004.01.08 15:37 Scott J. Tringali wrote: > TK Soh wrote: > > > I'll take a look, but let's try not to mix up between the two. Besides, the > > segfault to me is a much bigger problem. > > I'll look at the segfault, since I probably introduced it. Weird, only > happens on OpenMotif 2.1, though. It looks like a bug in OpenMotif, which is triggered by the changes. At least, I couldn't find anything wrong in our code, but I don't fully understand the OpenMotif code yet where it seems to go wrong. Eddy |
From: TK S. <tee...@ya...> - 2004-01-09 00:14:30
|
--- Eddy De Greef <de...@im...> wrote: > On 2004.01.08 15:37 Scott J. Tringali wrote: > > TK Soh wrote: > > > > > I'll take a look, but let's try not to mix up between the two. Besides, > the > > > segfault to me is a much bigger problem. > > > > I'll look at the segfault, since I probably introduced it. Weird, only > > happens on OpenMotif 2.1, though. > > It looks like a bug in OpenMotif, which is triggered by the changes. > At least, I couldn't find anything wrong in our code, but I don't > fully understand the OpenMotif code yet where it seems to go wrong. I managed to capture the widget hierarchy of the Shift_Left menu item from its tear-off, on both OM and Lesstif: Lesstif (0.93.x): ---------------- 0x83a96f8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 0x83a9b88: editMenu (XmRowColumn): x=616, y=151, w=189, h=342 0x84beee0: editMenu Tear-off (TransientShell): x=616, y=151, w=189, h=342 0x83881f0: text (TopLevelShell): x=544, y=92, w=620, h=655 0x834bb20: nedit (ApplicationShell): x=0, y=0, w=0, h=0 OM (2.1.30 and 2.2.3 beta): -------------------------- 0x83cf4a8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 0x83cd440: editMenu (XmRowColumn): x=47, y=207, w=189, h=342 0x841bc30: (TransientShell): x=47, y=207, w=189, h=342 0x8369b28: nedit (ApplicationShell): x=0, y=0, w=0, h=0 I also hacked OM-2.2.3b a bit to add the missing TopLevelShell, which seemed to fix the seg-fault. Now, the issue here is how we should workaround the broken OM. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Scott J. T. <sco...@et...> - 2004-01-09 00:59:58
|
TK Soh wrote: > I managed to capture the widget hierarchy of the Shift_Left menu item from its > tear-off, on both OM and Lesstif: > > Lesstif (0.93.x): > ---------------- > 0x83a96f8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > 0x83a9b88: editMenu (XmRowColumn): x=616, y=151, w=189, h=342 > 0x84beee0: editMenu Tear-off (TransientShell): x=616, y=151, w=189, h=342 > 0x83881f0: text (TopLevelShell): x=544, y=92, w=620, h=655 > 0x834bb20: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > OM (2.1.30 and 2.2.3 beta): > -------------------------- > 0x83cf4a8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > 0x83cd440: editMenu (XmRowColumn): x=47, y=207, w=189, h=342 > 0x841bc30: (TransientShell): x=47, y=207, w=189, h=342 > 0x8369b28: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > I also hacked OM-2.2.3b a bit to add the missing TopLevelShell, which seemed to > fix the seg-fault. Now, the issue here is how we should workaround the broken OM. This is at the time of the crash, right? I mean, during normal operation, the TopLevelShell is still there, right? Ugh, time to pull out a debug version of Motif and see what it's doing. What I saw was that it was placing the tear-off as a child of the ApplicationShell, not the TopLevelShell. |
From: TK S. <tee...@ya...> - 2004-01-09 03:38:30
|
--- "Scott J. Tringali" <sco...@et...> wrote: > TK Soh wrote: > > > I managed to capture the widget hierarchy of the Shift_Left menu item from > its > > tear-off, on both OM and Lesstif: > > > > Lesstif (0.93.x): > > ---------------- > > 0x83a96f8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > > 0x83a9b88: editMenu (XmRowColumn): x=616, y=151, w=189, h=342 > > 0x84beee0: editMenu Tear-off (TransientShell): x=616, y=151, w=189, h=342 > > 0x83881f0: text (TopLevelShell): x=544, y=92, w=620, h=655 > > 0x834bb20: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > > > OM (2.1.30 and 2.2.3 beta): > > -------------------------- > > 0x83cf4a8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > > 0x83cd440: editMenu (XmRowColumn): x=47, y=207, w=189, h=342 > > 0x841bc30: (TransientShell): x=47, y=207, w=189, h=342 > > 0x8369b28: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > > > I also hacked OM-2.2.3b a bit to add the missing TopLevelShell, which > seemed to > > fix the seg-fault. Now, the issue here is how we should workaround the > broken OM. > > This is at the time of the crash, right? I mean, during normal > operation, the TopLevelShell is still there, right? Ugh, time to pull > out a debug version of Motif and see what it's doing. > What I saw was that it was placing the tear-off as a child of the > ApplicationShell, not the TopLevelShell. If it helps, here's the patch to OM-2.2.3b I did: --- TearOff.c 2004/01/07 11:25:06 1.1 +++ TearOff.c 2004/01/09 03:22:14 @@ -949,7 +949,7 @@ * associated-widget's shell destruction. We'll make the connection to * associate-widget with XmNtransientFor. */ - for (toplevel = wid; XtParent(toplevel); ) + for (toplevel = wid; !XtIsTopLevelShell(toplevel) && XtParent(toplevel); ) toplevel = XtParent(toplevel); XtSetArg(args[0], XmNdeleteResponse, XmDO_NOTHING); __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Eddy De G. <de...@im...> - 2004-01-09 12:13:28
Attachments:
tearoff-crash.c
|
On 2004.01.09 04:38 TK Soh wrote: > > --- "Scott J. Tringali" <sco...@et...> wrote: > > TK Soh wrote: > > > > > I managed to capture the widget hierarchy of the Shift_Left menu item from > > its > > > tear-off, on both OM and Lesstif: > > > > > > Lesstif (0.93.x): > > > ---------------- > > > 0x83a96f8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > > > 0x83a9b88: editMenu (XmRowColumn): x=616, y=151, w=189, h=342 > > > 0x84beee0: editMenu Tear-off (TransientShell): x=616, y=151, w=189, h=342 > > > 0x83881f0: text (TopLevelShell): x=544, y=92, w=620, h=655 > > > 0x834bb20: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > > > > > OM (2.1.30 and 2.2.3 beta): > > > -------------------------- > > > 0x83cf4a8: shiftLeft (XmPushButton): x=2, y=182, w=185, h=22 > > > 0x83cd440: editMenu (XmRowColumn): x=47, y=207, w=189, h=342 > > > 0x841bc30: (TransientShell): x=47, y=207, w=189, h=342 > > > 0x8369b28: nedit (ApplicationShell): x=0, y=0, w=0, h=0 > > > > > > I also hacked OM-2.2.3b a bit to add the missing TopLevelShell, which > > seemed to > > > fix the seg-fault. Now, the issue here is how we should workaround the > > broken OM. > > > > This is at the time of the crash, right? I mean, during normal > > operation, the TopLevelShell is still there, right? Ugh, time to pull > > out a debug version of Motif and see what it's doing. > > What I saw was that it was placing the tear-off as a child of the > > ApplicationShell, not the TopLevelShell. > > If it helps, here's the patch to OM-2.2.3b I did: > > --- TearOff.c 2004/01/07 11:25:06 1.1 > +++ TearOff.c 2004/01/09 03:22:14 > @@ -949,7 +949,7 @@ > * associated-widget's shell destruction. We'll make the connection to > * associate-widget with XmNtransientFor. > */ > - for (toplevel = wid; XtParent(toplevel); ) > + for (toplevel = wid; !XtIsTopLevelShell(toplevel) && XtParent(toplevel); ) > toplevel = XtParent(toplevel); > > XtSetArg(args[0], XmNdeleteResponse, XmDO_NOTHING); As far as I can see, the widget hierarchy is rearranged during destruction, and the tear-off menu is attached to some other widget. Then that widget is destroyed, and then the tear-off menu is destroyed. During that last step, the tear-off menu tries to disconnect itself from the already destroyed widget, causing the crash. It's very hard to see what is going on exactly, because there seem to be several hidden widgets involved. I've managed to construct a small test case that triggers the crash (file attached). It is sufficient to have 1 window and 1 tear-off menu. I'll file a bug report, but that should not stop us from trying to find a workaround. Eddy |
From: Scott J. T. <sco...@et...> - 2004-01-09 15:25:22
|
So this forces the tear-off menu's parent to be the shell (like normal) instead of the application shell. I wonder if Motif is forgetting to delete the menu and has a dangling pointer to it. I tried manually closing all the popup menus inside CloseWindow but it didn't work for everything. If we can't fix this I will revert the change - the cleanup is not worth introducing this bug. I can reproduce this outside of NEdit, too, so it appears to be a Motif 2.1 bug. |
From: Eddy De G. <de...@im...> - 2004-01-09 18:03:11
|
On 2004.01.09 16:25 Scott J. Tringali wrote: > I can reproduce this outside of NEdit, too, so it appears to be a Motif 2.1 > bug. Maybe not. I found this in the OSF/Motif programmer's guide: # TopLevelShell: TopLevelShell is used for normal toplevel windows. It is not # the root shell used by an application, rather it is normally used to create # peer toplevel windows in situations where an application needs more than one # set of windows. The root shell is normally the ApplicationShell. # # # ApplicationShell - ApplicationShell is an application's toplevel or root # window. This is the shell that is created by XtAppInitialize. An application # should not have more than one ApplicationShell. Subsequent toplevel shells ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # should be of class TopLevelShell and are created by XtAppCreateShell. These ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ # toplevel shells can be considered the root of a second widget tree for the # application. So, what we did in the past, namely creating multiple ApllicationShells, was wrong (which was probably the cause for the session management bugs), but what we do now, creating topLevelShells as child widgets, is probably also wrong. When I change my test example to create the toplevel shells with XtAppCreateShell, as the text above says, it doesn't crash any more. When do the same in NEdit, everything seems to work fine too. So, in the end, the error seems to be on our side. Eddy BTW: On HPUX/OSF-Motif-2.x, my test case doesn't crash, but Purify complains about some rather serious errors, so the problem is not restricted to OpenMotif. |
From: TK S. <tee...@ya...> - 2004-01-10 01:30:52
|
--- Eddy De Greef <de...@im...> wrote: > On 2004.01.09 16:25 Scott J. Tringali wrote: > > I can reproduce this outside of NEdit, too, so it appears to be a Motif 2.1 > > bug. > > Maybe not. I found this in the OSF/Motif programmer's guide: > > # TopLevelShell: TopLevelShell is used for normal toplevel windows. It is not > # the root shell used by an application, rather it is normally used to create > # peer toplevel windows in situations where an application needs more than > one > # set of windows. The root shell is normally the ApplicationShell. > # > # > # ApplicationShell - ApplicationShell is an application's toplevel or root > # window. This is the shell that is created by XtAppInitialize. An > application > # should not have more than one ApplicationShell. Subsequent toplevel shells > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > # should be of class TopLevelShell and are created by XtAppCreateShell, These > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > # toplevel shells can be considered the root of a second widget tree for the > # application. Volumn 6A did mention we should use XtAppCreateShell for permanent windows, but it gave no warnings otherwise. > So, what we did in the past, namely creating multiple ApllicationShells, was > wrong > (which was probably the cause for the session management bugs), but what we > do now, > creating topLevelShells as child widgets, is probably also wrong. > > When I change my test example to create the toplevel shells with > XtAppCreateShell, > as the text above says, it doesn't crash any more. Would switching to XtAppCreateShell defeat the original intention of the hierarchy change? If not, perhaps someone can help put in the fix please. Honestly, this seg-fault thing is making me very uncomfortable. > BTW: On HPUX/OSF-Motif-2.x, my test case doesn't crash, but Purify complains > about > some rather serious errors, so the problem is not restricted to OpenMotif. Any complains when using XtAppCreateShell? In any case, as long as it's working, i.e. no crashes, I wouldn't want to worry much about them. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Eddy De G. <edd...@ti...> - 2004-01-10 14:41:17
|
Op 10-01-04 02:30:46 schreef TK Soh: > --- Eddy De Greef <de...@im...> wrote: > Volumn 6A did mention we should use XtAppCreateShell for permanent > windows, but it gave no warnings otherwise. > > > So, what we did in the past, namely creating multiple > > ApllicationShells, was wrong > > (which was probably the cause for the session management bugs), but > > what we do now, > > creating topLevelShells as child widgets, is probably also wrong. > > > > When I change my test example to create the toplevel shells with > > XtAppCreateShell, as the text above says, it doesn't crash any > > more. > > Would switching to XtAppCreateShell defeat the original intention of > the hierarchy change? Perhaps, but I don't know exactly what the problems where that Scott wanted to tackle. Anyway, the former hierarchy was definitely not valid. There should have been only one ApplicationShell. > If not, perhaps someone can help put in the fix > please. Honestly, this seg-fault thing is making me very > uncomfortable. > > > BTW: On HPUX/OSF-Motif-2.x, my test case doesn't crash, but Purify > > complains about some rather serious errors, so the problem is not > > restricted to OpenMotif. > > Any complains when using XtAppCreateShell? In any case, as long as > it's working, i.e. no crashes, I wouldn't want to worry much about > them. I would. I'm not talking about uninitialized memory reads (of which I get lots of warnings in Motif) which are often harmless, but about free memory reads and writes. It is just luck if it doesn't crash. I didn't get any of those errors when I used XtAppCreateShell (on my test example, I didn't try it with NEdit). Eddy |
From: Scott J. T. <sco...@et...> - 2004-01-10 16:20:08
|
Eddy De Greef wrote: > Perhaps, but I don't know exactly what the problems where that Scott > wanted to tackle. Anyway, the former hierarchy was definitely not > valid. There should have been only one ApplicationShell. Aside from following the documentation, the application shell can serve as a group leader (removing the need to create an invisible window to do this), it lets you set different windows with different resources. I also think it will fix two problems that we've worked around - manually propogating visual/colormap/etc to new windows, and bugs session in management. If you have 10 application shells, then the session manager thinks there are ten applications. If I can't find a workaround that allows tear-offs to work, I'll pull out the fix. I've tried manually closing the popups but I suspect something is the reverse, somethings is double-deleting a shell. |
From: TK S. <tee...@ya...> - 2004-01-11 13:19:28
|
--- "Scott J. Tringali" <sco...@et...> wrote: > Eddy De Greef wrote: > > > Perhaps, but I don't know exactly what the problems where that Scott > > wanted to tackle. Anyway, the former hierarchy was definitely not > > valid. There should have been only one ApplicationShell. > > Aside from following the documentation, the application shell can serve > as a group leader (removing the need to create an invisible window to do > this), it lets you set different windows with different resources. > > I also think it will fix two problems that we've worked around - > manually propogating visual/colormap/etc to new windows, and bugs > session in management. If you have 10 application shells, then the > session manager thinks there are ten applications. > > If I can't find a workaround that allows tear-offs to work, I'll pull > out the fix. I've tried manually closing the popups but I suspect > something is the reverse, somethings is double-deleting a shell. Have you tried out XtAppCreateShell? Anyway, I hacked a little on closing the popup: it did avoid the crash if I destroy the popup's XmRowColumn followed by its TransientShell parent bofore closing the window. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: TK S. <tee...@ya...> - 2004-01-11 13:25:15
|
--- Eddy De Greef <edd...@ti...> wrote: > Op 10-01-04 02:30:46 schreef TK Soh: > > --- Eddy De Greef <de...@im...> wrote: > > Volumn 6A did mention we should use XtAppCreateShell for permanent > > windows, but it gave no warnings otherwise. > > > > > So, what we did in the past, namely creating multiple > > > ApllicationShells, was wrong > > > (which was probably the cause for the session management bugs), but > > > what we do now, > > > creating topLevelShells as child widgets, is probably also wrong. > > > > > > When I change my test example to create the toplevel shells with > > > XtAppCreateShell, as the text above says, it doesn't crash any > > > more. > > > > Would switching to XtAppCreateShell defeat the original intention of > > the hierarchy change? > > Perhaps, but I don't know exactly what the problems where that Scott > wanted to tackle. Anyway, the former hierarchy was definitely not > valid. There should have been only one ApplicationShell. > > > If not, perhaps someone can help put in the fix > > please. Honestly, this seg-fault thing is making me very > > uncomfortable. > > > > > BTW: On HPUX/OSF-Motif-2.x, my test case doesn't crash, but Purify > > > complains about some rather serious errors, so the problem is not > > > restricted to OpenMotif. > > > > Any complains when using XtAppCreateShell? In any case, as long as > > it's working, i.e. no crashes, I wouldn't want to worry much about > > them. > > I would. I'm not talking about uninitialized memory reads (of which > I get lots of warnings in Motif) which are often harmless, but about > free memory reads and writes. It is just luck if it doesn't crash. > I didn't get any of those errors when I used XtAppCreateShell (on my > test example, I didn't try it with NEdit). I vaguely remember trying out valgrind on nedit about 18 months back, and also getting some complains about free memory reads and writes. But I didn't know much about nedit-motif-valgrind back then, or even now. My main question is the validity of those complains. Have you tried running Purity on 5.4? __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: TK S. <tee...@ya...> - 2004-01-11 14:13:18
|
--- TK Soh <tee...@ya...> wrote: > --- Eddy De Greef <edd...@ti...> wrote: > > > > BTW: On HPUX/OSF-Motif-2.x, my test case doesn't crash, but Purify > > > > complains about some rather serious errors, so the problem is not > > > > restricted to OpenMotif. > > > > > > Any complains when using XtAppCreateShell? In any case, as long as > > > it's working, i.e. no crashes, I wouldn't want to worry much about > > > them. > > > > I would. I'm not talking about uninitialized memory reads (of which > > I get lots of warnings in Motif) which are often harmless, but about > > free memory reads and writes. It is just luck if it doesn't crash. > > I didn't get any of those errors when I used XtAppCreateShell (on my > > test example, I didn't try it with NEdit). > > I vaguely remember trying out valgrind on nedit about 18 months back, and > also > getting some complains about free memory reads and writes. But I didn't know > much about nedit-motif-valgrind back then, or even now. My main question is > the validity of those complains. Have you tried running Purity on 5.4? I think I was, and still am, confused here. Do you mean that with your test case, those warnings on free memory reads and writes went away if you used XtAppCreateShell? If so, switching to XtAppCreateShell should be right thing to do. Anyway, correct me if I'm wrong, I think we're looking at two separate, though not totally unrelated, issues here: i) the use of XtAppCreateShell (that fix the tearoff problem) and, ii) the complains Purify generated on Motif (which is reduced by the use of XtAppCreateShell). If this is the case, let's fix the tearoff problem first. Once again, I'm still not 100% clear. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Eddy De G. <edd...@ti...> - 2004-01-11 14:41:34
|
TK Soh <tee...@ya...> wrote: > I think I was, and still am, confused here. Do you mean that with > your test case, those warnings on free memory reads and writes went > away if you used XtAppCreateShell? If so, switching to > XtAppCreateShell should be right thing to do. Yes. > Anyway, correct me if I'm wrong, I think we're looking at two > separate, though not totally unrelated, issues here: i) the use of > XtAppCreateShell (that fix the tearoff problem) and, ii) the > complains Purify generated on Motif (which is reduced by the use of > XtAppCreateShell). If this is the case, let's fix the > tearoff problem first. > > Once again, I'm still not 100% clear. Purify always generates lots of warnings on Motif. Most of them are harmless, and we shouldn't worry about those. The changed widget hierarchy gives rise to some more serious errors that we didn't get before. I mentioned this because it enforces my suspicions that we really do something wrong (even though it doesn't crash on HPUX/Motif2, yet). Eddy |
From: Joerg F. <jf...@gm...> - 2004-01-08 18:18:35
|
>Also, folks, sign up for the mailing lists on SF -=20 You mean nedit-discuss, too? BTW, would it be possible to use a virtual mail address that only points to a list server and could be switched to another list when a server is off-line like now? Cheers, J=F6rg |
From: Joerg F. <jf...@gm...> - 2004-01-09 02:09:44
|
>I caught a seg fault with CVS head revision when linked to >OM-2.1.30, and later traced it back to the changes on widget >hierarchy of top-level application shell. Lesstif appeared to be >okay. >=20 > To create the seg fault: > 1. open two _windows_. > 2. tear off the File menu of any one window. > 3. close the window with the tear-off menu. Does open two windows mean open two tabs or two windows in non-buffermode? What I've done is opened two tabs, torn off the File menu (tried later also different menus) and closed the tab with the tear-off menu. But nothing happens. This is with 07.01 Head and OM 2.1.30 (the Metrolink version). Am I missing anything? Cheers, J=F6rg |
From: TK S. <tee...@ya...> - 2004-01-09 03:03:45
|
--- Joerg Fischer <jf...@gm...> wrote: > >I caught a seg fault with CVS head revision when linked to > >OM-2.1.30, and later traced it back to the changes on widget > >hierarchy of top-level application shell. Lesstif appeared to be > >okay. > > > > To create the seg fault: > > 1. open two _windows_. > > 2. tear off the File menu of any one window. > > 3. close the window with the tear-off menu. > > Does open two windows mean open two tabs or two windows in > non-buffermode? What I've done is opened two tabs, torn off the File > menu (tried later also different menus) and closed the tab with the > tear-off menu. But nothing happens. This is with 07.01 Head and OM > 2.1.30 (the Metrolink version). > > Am I missing anything? "_windows_". __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Joerg F. <jf...@gm...> - 2004-01-09 03:59:27
|
> "_windows_". Ok, I see it now with OM, but still not with lesstif. Cheers, J=F6rg |
From: TK S. <tee...@ya...> - 2004-01-09 04:20:19
|
--- Joerg Fischer <jf...@gm...> wrote: > > "_windows_". > > Ok, I see it now with OM, but still not with lesstif. Lesstif does not have this problem. __________________________________ Do you Yahoo!? Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus |
From: Joerg F. <jf...@gm...> - 2004-01-09 03:59:27
|
> Macro menu entry with insert_string("Ooops") bound to Ctrl-D > Open two windows, select the second one, hit Ctrl-D. Then the Ooops > is in the first window.=20 I checked again with a clean version on both Linux and Cygwin with 5.5 [Under Development] HEAD Jan 8, 2004 The problem is there. Only the description above is bad. If you are in the second window first and hit the short-cut then the macro is executed there. BUT if you switch to the first window thereafter and hit the short-cut again then the macro gets still executed in the second window.=20 This holds only for short-cuts. Invoking the macro from the macro menu works always in the right window. Cheers, J=F6rg |
From: Joerg F. <jf...@gm...> - 2004-01-07 15:53:01
|
> Folks, >=20 > If you head over to http://sourceforge.net/mail/?group_id=3D11005 you can > subscribe to the mailing list there. Then send mail to > ned...@li...... Ok, done. Cheers, J=F6rg |