Version-Release number of selected component:
libreport version: 2.0.18
cmdline: xterm -hold -e ./amd-catalys.run
:Thread no. 1 (10 frames)
: #0 AlternateScroll at ./scrollbar.c:706
: #2 HandleActions at TMstate.c:645
: #3 HandleSimpleState at TMstate.c:884
: #4 _XtTranslateEvent at TMstate.c:1101
: #5 XtDispatchEventToWidget at Event.c:906
: #6 _XtDefaultDispatcher at Event.c:1367
: #7 XtDispatchEvent at Event.c:1423
: #8 xevents at ./misc.c:645
: #9 Cleanup at ./misc.c:4883
: #10 readPtyData at ./ptydata.c:214
Created attachment 640450 [details]
Created attachment 640451 [details]
Created attachment 640452 [details]
Created attachment 640453 [details]
Created attachment 640454 [details]
Created attachment 640455 [details]
Created attachment 640456 [details]
Created attachment 640457 [details]
Created attachment 640458 [details]
Created attachment 640459 [details]
Created attachment 640460 [details]
Created attachment 640461 [details]
Can you please update to xterm-286-1.fc17 and see if the problem persist?
I don't think that will change (it's recent but no rework was done).
In a quick check here, I don't see it breaking. However the new
code (which is being exercised) could break if the event did not
pass the xterm-widget but rather some other widget. In other places
I guarded against that by calling getXtermWidget() rather than casting
The report does not show the X resource settings; given the traceback
it seems that the alternateScroll resource would be set. If the widget
is not really xterm, then the associated screen pointer would be invalid
(whether or not the alternateScroll resource was set).
It would be nice to have the X resource settings (and some clue of the
user's interactions with xterm) to see which path led to this.
However, adding a guard inside AlternateScroll() would not change
xterm's behavior since there is already one in AmountToScroll()
which is used in each of the callers. I don't think there is
enough information here for me to reproduce the problem.
I can reproduce the problem at will by placing the mouse over the scroll bar and scrolling up using the scroll wheel. Works every time. Note that scrolling using the mouse wheel in the text area works fine, only scrolling up using the scroll wheel in the scroll bar produces the problem.
The difference (if any) between the two is that the action within
the scrollback is added using XtAugmentTranslations. A long time
ago (say more than ten years ago) there were some systems which
didn't work well with that (seems they had some tablesize limit?).
But I'm not seeing the same problem with the Fedora package for
xterm in Fedora18 - so I'm still stuck. Clicking up/down and
dragging all work - here.
Don't click or drag. Both of those actions work for me too. Just place the mouse pointer over the scrollbar and use the scrollwheel. If you want i can post details of my hardware configuration...
I did that, too. But Matthieu Herrb's followup to me indicating
your additional traceback, etc, got me to notice the attachment
in comment #4 and realize that getXtermWidget() is needed in this
Created attachment 703182 [details]
for the problem (in #291)
I'll prepare f17 and f18 updates shortly.
xterm-291-1.fc17 has been submitted as an update for Fedora 17.
xterm-291-1.fc18 has been submitted as an update for Fedora 18.
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xterm-291-1.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Tested it on Fedora 17 - works great. Thanks!
*** Bug 919644 has been marked as a duplicate of this bug. ***
xterm-291-1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
xterm-291-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.