Bug 143180

Created attachment 108772 [details]
backtrace from AbiWord crash

Damn. It apparently works on i386 with abiword-2.0.12-7.fc3.

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
that.

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.

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
(this=0xcf6bf0, 
    eb=88) at ev_EditBinding.cpp:169
#1  0x00000000005c9f31 in EV_EditEventMapper::Mouse (this=0xd94560,
eb=88, 
    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
short.

The next level up in gdb looks like follows:

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

Created attachment 108878 [details]
Patch committed to cvs for this bug

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

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'
failed

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.

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).

Created attachment 108994 [details]
Patch committed to cvs for this bug

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
libgsf.

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!