Bug 874327

Summary: [abrt] xterm-284-1.fc17: AlternateScroll: Process /usr/bin/xterm was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: hywel <turquino>
Component: xtermAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: andrewdavis.davis, apcomptec, dickey, mlichvar, mplmpl, pertusus, sebastian, wagnerdocri
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:6ec61eb3f45cbb0cf0e8b31886b434d415b5b6fc
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 08:52:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: core_backtrace
none
File: environ
none
File: limits
none
File: backtrace
none
File: cgroup
none
File: smolt_data
none
File: executable
none
File: maps
none
File: dso_list
none
File: proc_pid_status
none
File: var_log_messages
none
File: open_fds
none
for the problem (in #291) none

Description hywel 2012-11-07 22:53:23 UTC
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 1 hywel 2012-11-07 22:53:26 UTC
Created attachment 640450 [details]
File: core_backtrace

Comment 2 hywel 2012-11-07 22:53:28 UTC
Created attachment 640451 [details]
File: environ

Comment 3 hywel 2012-11-07 22:53:29 UTC
Created attachment 640452 [details]
File: limits

Comment 4 hywel 2012-11-07 22:53:31 UTC
Created attachment 640453 [details]
File: backtrace

Comment 5 hywel 2012-11-07 22:53:33 UTC
Created attachment 640454 [details]
File: cgroup

Comment 6 hywel 2012-11-07 22:53:35 UTC
Created attachment 640455 [details]
File: smolt_data

Comment 7 hywel 2012-11-07 22:53:36 UTC
Created attachment 640456 [details]
File: executable

Comment 8 hywel 2012-11-07 22:53:38 UTC
Created attachment 640457 [details]
File: maps

Comment 9 hywel 2012-11-07 22:53:40 UTC
Created attachment 640458 [details]
File: dso_list

Comment 10 hywel 2012-11-07 22:53:41 UTC
Created attachment 640459 [details]
File: proc_pid_status

Comment 11 hywel 2012-11-07 22:53:43 UTC
Created attachment 640460 [details]
File: var_log_messages

Comment 12 hywel 2012-11-07 22:53:45 UTC
Created attachment 640461 [details]
File: open_fds

Comment 13 Miroslav Lichvar 2012-11-08 07:57:32 UTC
Can you please update to xterm-286-1.fc17 and see if the problem persist?

Comment 14 Thomas E. Dickey 2012-11-09 21:15:43 UTC
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 10:00:27 UTC
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 18:07:39 UTC
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 20:39:07 UTC
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 22:49:19 UTC
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 23:29:51 UTC
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-27 00:14:24 UTC
Created attachment 703182 [details]
for the problem (in #291)

Comment 21 Miroslav Lichvar 2013-02-28 10:49:42 UTC
Thanks, Thomas.

I'll prepare f17 and f18 updates shortly.

Comment 22 Fedora Update System 2013-02-28 11:25:47 UTC
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 11:27:22 UTC
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 20:04:38 UTC
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 14:46:28 UTC
Tested it on Fedora 17 - works great. Thanks!

Comment 26 Miroslav Lichvar 2013-03-11 08:30:37 UTC
*** Bug 919644 has been marked as a duplicate of this bug. ***

Comment 27 Fedora Update System 2013-03-12 08:48:38 UTC
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 08:52:32 UTC
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.