Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[abrt] xterm-284-1.fc17: AlternateScroll: Process /usr/bin/xterm was killed by signal 11 (SIGSEGV)|
|Product:||[Fedora] Fedora||Reporter:||hywel <turquino>|
|Component:||xterm||Assignee:||Miroslav Lichvar <mlichvar>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||andrewdavis.davis, apcomptec, dickey, mlichvar, mplmpl, pertusus, sebastian, wagnerdocri|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-12 04:52:30 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description hywel 2012-11-07 17:53:23 EST
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
Comment 13 Miroslav Lichvar 2012-11-08 02:57:32 EST
Can you please update to xterm-286-1.fc17 and see if the problem persist?
Comment 14 Thomas E. Dickey 2012-11-09 16:15:43 EST
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.
Comment 15 Thomas E. Dickey 2012-11-19 05:00:27 EST
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.
Comment 16 Mike Lindner 2013-02-26 13:07:39 EST
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.
Comment 17 Thomas E. Dickey 2013-02-26 15:39:07 EST
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.
Comment 18 Mike Lindner 2013-02-26 17:49:19 EST
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...
Comment 19 Thomas E. Dickey 2013-02-26 18:29:51 EST
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.
Comment 20 Thomas E. Dickey 2013-02-26 19:14:24 EST
Created attachment 703182 [details] for the problem (in #291)
Comment 21 Miroslav Lichvar 2013-02-28 05:49:42 EST
Thanks, Thomas. I'll prepare f17 and f18 updates shortly.
Comment 22 Fedora Update System 2013-02-28 06:25:47 EST
xterm-291-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/xterm-291-1.fc17
Comment 23 Fedora Update System 2013-02-28 06:27:22 EST
xterm-291-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/xterm-291-1.fc18
Comment 24 Fedora Update System 2013-03-02 15:04:38 EST
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).
Comment 25 Mike Lindner 2013-03-04 09:46:28 EST
Tested it on Fedora 17 - works great. Thanks!
Comment 26 Miroslav Lichvar 2013-03-11 04:30:37 EDT
*** Bug 919644 has been marked as a duplicate of this bug. ***
Comment 27 Fedora Update System 2013-03-12 04:48:38 EDT
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.
Comment 28 Fedora Update System 2013-03-12 04:52:32 EDT
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.