Version-Release number of selected component: xterm-284-1.fc17 Additional info: libreport version: 2.0.18 abrt_version: 2.0.18 backtrace_rating: 4 cmdline: xterm -hold -e ./amd-catalys.run crash_function: AlternateScroll kernel: 3.6.3-1.fc17.x86_64 truncated backtrace: :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] File: core_backtrace
Created attachment 640451 [details] File: environ
Created attachment 640452 [details] File: limits
Created attachment 640453 [details] File: backtrace
Created attachment 640454 [details] File: cgroup
Created attachment 640455 [details] File: smolt_data
Created attachment 640456 [details] File: executable
Created attachment 640457 [details] File: maps
Created attachment 640458 [details] File: dso_list
Created attachment 640459 [details] File: proc_pid_status
Created attachment 640460 [details] File: var_log_messages
Created attachment 640461 [details] File: open_fds
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 value. 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 case.
Created attachment 703182 [details] for the problem (in #291)
Thanks, Thomas. I'll prepare f17 and f18 updates shortly.
xterm-291-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xterm-291-1.fc17
xterm-291-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xterm-291-1.fc18
Package xterm-291-1.fc17: * 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: https://admin.fedoraproject.org/updates/FEDORA-2013-3250/xterm-291-1.fc17 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.