Bug 143180 - [x86_64]abiword dies with SIGSEGV on a double click to open a file
Summary: [x86_64]abiword dies with SIGSEGV on a double click to open a file
Alias: None
Product: Fedora
Classification: Fedora
Component: abiword (Show other bugs)
(Show other bugs)
Version: 3
Hardware: x86_64 Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-17 02:59 UTC by Michal Jaegermann
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-22 18:03:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace from AbiWord crash (4.34 KB, text/plain)
2004-12-17 03:00 UTC, Michal Jaegermann
no flags Details

Description Michal Jaegermann 2004-12-17 02:59:20 UTC
Description of problem:

An attempt to open an existing file in a file selector of AbiWord
works fine if one highlights the name and clicks an "OK" button;
but a double click on a name ends up with a consistent segmentation
fault instead.

Backtrace from gdb is pretty long, fity nine steps, so it is
attached and not in-line.  I did not have an opportunity to try
that on FC3 x86 installation but on x86_64 this is repeatable
with a vengeance.

Opening a file by name as an argument from a command line seems
to be fine.

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Michal Jaegermann 2004-12-17 03:00:15 UTC
Created attachment 108772 [details]
backtrace from AbiWord crash

Comment 2 Caolan McNamara 2004-12-17 10:55:30 UTC
Damn. It apparently works on i386 with abiword-2.0.12-7.fc3.

Comment 3 Michal Jaegermann 2004-12-17 18:03:36 UTC
It could be a race and maybe a window on i386 is harder to hit than
on x86_64.

The reason for that suggestion is that when I run into the problem
in the first place I was quite surprised and I did not pay attention
in which way I was opening a file.  It is quite possible that this
was _not_ by a double click in a file selector but I cannot swear to

By the time I started systematic checks, and realized that results
depend on how I am trying to open a file, I was getting consistently
SIGSEGV on a double click, with a backtrace as attached, and no
such incidents after "highlight and click OK".  Also I opened files
fine with 'abiword some_file.{doc,rtf,abw}' but it may be that the
first SIGSEGV actually happened that way.  I really cannot tell now.

Comment 4 Michal Jaegermann 2004-12-20 00:15:01 UTC
I tried to reproduce the problem on "devel" installation and
with abiword-2.2.2-1.  This did not work at all.  OTOH I can
reproduce that crash with abiword-2.0.12-7.fc3.x86_64 although
in some situations it takes multiple tries before that happens
and other times it is absolutetely reliable.

Every time this happens it leaves a new file with an old name
with appended ".CRASHED" to it so one can have quickly
<some_name>.CRASHED.CRASHED.CRASHED.CRASHED in no time at all. :-)

After loading debuginfo this is what I see in gdb:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 182894267072 (LWP 26998)]
0x00000000005c97f6 in EV_EditBindingMap::findEditBinding
(this=0xcf6bf0, eb=88)
    at ev_EditBinding.cpp:169
169			return p->m_peb[n_emo][n_ems][n_emc];
(gdb) l
164			if (!p)
165				return 0;					
// no bindings of anykind for this mouse button
166			UT_uint32 n_emo = EV_EMO_ToNumber(eb)-1;
167			UT_uint32 n_ems = EV_EMS_ToNumber(eb);
168			UT_uint32 n_emc = EV_EMC_ToNumber(eb)-1;
169			return p->m_peb[n_emo][n_ems][n_emc];
170		}
171		else if (EV_IsKeyboard(eb))			// a keyevent, find out what kind
172		{
173			if (eb & EV_EKP_NAMEDKEY)		// a NVK
(gdb) p p
$1 = (ev_EB_MouseTable *) 0xcf6bf0

and these are the lowest levels of backtrace:

#0  0x00000000005c97f6 in EV_EditBindingMap::findEditBinding
    eb=88) at ev_EditBinding.cpp:169
#1  0x00000000005c9f31 in EV_EditEventMapper::Mouse (this=0xd94560,
    ppEM=0x7fbfffdd80) at ev_EditEventMapper.cpp:57
#2  0x00000000005cf79e in EV_UnixMouse::mouseUp (this=0xd94bf0, 
    pView=0x12fd860, e=0xd2d1e0) at ev_UnixMouse.cpp:86
#3  0x00000000005a40b6 in XAP_UnixFrameImpl::_fe::button_release_event (
    w=0xfc35d0, e=0xd2d1e0) at xap_UnixFrameImpl.cpp:528

The value of a pointer to ev_EB_MouseTable above looks strangely

The next level up in gdb looks like follows:

(gdb) up
#1  0x00000000005c9f31 in EV_EditEventMapper::Mouse (this=0xd94560,
    ppEM=0x7fbfffdd80) at ev_EditEventMapper.cpp:57
57		EV_EditBinding * peb = m_pebmInProgress->findEditBinding(eb);
(gdb) l
52	#endif
54		if (!m_pebmInProgress)
55			m_pebmInProgress = m_pebmTopLevel;
57		EV_EditBinding * peb = m_pebmInProgress->findEditBinding(eb);
58		if (!peb)							
// bogus key
59		{
60			EV_EditEventMapperResult r = (  (m_pebmInProgress==m_pebmTopLevel)

Comment 5 Red Hat CVS System 2004-12-20 09:10:59 UTC
Created attachment 108878 [details]
Patch committed to cvs for this bug

Comment 6 Caolan McNamara 2004-12-20 09:38:43 UTC
caolanm->Michal: Want to give
http://people.redhat.com/caolanm/abiword/abiword-2.0.12-8.x86_64.rpm a
try to see if that backport fixes the problem

Comment 7 Michal Jaegermann 2004-12-20 18:53:14 UTC
With abiword-2.0.12-8.x86_64 so far I did not manage, so far :-),
to cause a crash like the one above.

I got with it on a console:
(AbiWord:31998): libgsf:msole-CRITICAL **: file gsf-infile-msole.c:
line 112 (ole_get_block): assertion `block < ole->info->max_block'

and also for every of my test files opened, and possibly closed
and some other operations too,

(AbiWord:31998): Gtk-WARNING **: Invalid input string

This does not show up if I am typing 'abiword some_file' but
playing with a file selector generates the above.

Moreover one of files opened zoomed down to a size of a somewhat
bigger post stamp but stretching a window, with zoom set to a page
width, restored a bit more useful view.  Loking closer that would
be a file of a 'Microsoft Office Document' type and the one
for which I got that "msole-CRITICAL" complaint.

Comment 8 Michal Jaegermann 2004-12-20 19:10:55 UTC
I can cause any amount of

Gtk-WARNING **: Invalid input string

simply by opening one of drop-menus and sliding my mouse right
and left across a toolbar so other menus drop and hide.

Any of M$-word files will end up with

  assertion `block < ole->info->max_block' failed

on open but that tiny initial size seems like a property of
a particular one (not that I did knowingly something to cause that).

Comment 9 Red Hat CVS System 2004-12-22 09:20:16 UTC
Created attachment 108994 [details]
Patch committed to cvs for this bug

Comment 10 Caolan McNamara 2004-12-22 18:03:43 UTC
I've pushed an update as abiword-2.0.12-9 which should fix the 64bit
substantive issue and also as a bonus the seperate "Invalid input
string" problem.

The "block < ole->" etc message is from libgsf not abiword, it appears
cosmetic, i.e. not related to the document size problem. If you feel
strongly about the warning message you can open a seperate bug against

Comment 11 Michal Jaegermann 2004-12-22 18:23:34 UTC
I am not that miffed about warnings.  I quote this stuff as it may
sometimes help to find the underlying problem (although it nicer
not to have scary failed asserts :-).  Thanks!

Note You need to log in before you can comment on or make changes to this bug.