[patch] Fix null deference at FindAndReplace.cpp:358

[John McCabe-Dansted]

Hi, I got the following backtrace. It is not really possible to
manually reproduce (the recipe has 1779 keypresses, see [1]); however,
this looks like a simple Null dereference. At a glance it seems that
the attached patch should fix the problem, and I can no longer
reproduce a crash with the patch applied. Does the patch look OK?

[1] http://gmatht.homelinux.net/xp/keytest/html_out/out/t15/misc/

Also should I go through all the backtraces generated by keytest and
harden the areas of code where a Null dereference has occured (even if
I do not know how to reproduce)? If so should I be adding some thing
line
ASSERT(buf) // There shouldn't be a null here but keytest claims there can be
?

Program received signal SIGSEGV, Segmentation fault.
lyx::Buffer::absFileName (this=0x0) at Buffer.cpp:2513
2513 return d->filename.absFileName();
(gdb) #0 lyx::Buffer::absFileName (this=0x0) at Buffer.cpp:2513
#1 0x0000000000d43dd9 in
lyx::frontend::FindAndReplaceWidget::findAndReplaceScope
(this=0x21c4c70, opt=<value optimised out>,
replace_all=<value optimised out>) at FindAndReplace.cpp:358
#2 0x0000000000d4557c in lyx::frontend::FindAndReplaceWidget::findAndReplace (
this=0x21c4c70, casesensitive=<value optimised out>,
matchword=<value optimised out>, backwards=<value optimised out>,
expandmacros=<value optimised out>, ignoreformat=<value optimised out>,
replace=true, keep_case=false, replace_all=48) at FindAndReplace.cpp:428
#3 0x0000000000d45a21 in lyx::frontend::FindAndReplaceWidget::findAndReplace (
this=0x21c4c70, backwards=6, replace=true, replace_all=false)
at FindAndReplace.cpp:454
#4 0x0000000000d45bff in
lyx::frontend::FindAndReplaceWidget::on_replacePB_clicked
(this=0x21c4c70) at FindAndReplace.cpp:473
#5 0x0000000000d45cbc in lyx::frontend::FindAndReplaceWidget::qt_metacall (
this=0x21c4c70, _c=QMetaObject::InvokeMetaMethod,
_id=<value optimised out>, _a=<value optimised out>)
at moc_FindAndReplace.cpp:79
#6 0x00007ffff607ae3f in QMetaObject::activate (sender=0x21e8e00,
m=<value optimised out>, local_signal_index=<value optimised out>,
argv=0x6) at kernel/qobject.cpp:3293
#7 0x00007ffff6bd65f2 in QAbstractButton::clicked (this=0x7fffffff9610,
_t1=false) at .moc/release-shared/moc_qabstractbutton.cpp:206
#8 0x00007ffff68f086b in QAbstractButtonPrivate::emitClicked (this=0x21f5fd0)
at widgets/qabstractbutton.cpp:546
#9 0x00007ffff68f170b in QAbstractButtonPrivate::click (this=0x21f5fd0)
at widgets/qabstractbutton.cpp:539
#10 0x00007ffff68f17ec in QAbstractButton::timerEvent (this=0x21e8e00,
e=<value optimised out>) at widgets/qabstractbutton.cpp:1258
#11 0x00007ffff6077a63 in QObject::event (this=0x21e8e00, e=0x7fffffffa4a0)
at kernel/qobject.cpp:1212
#12 0x00007ffff6590bdf in QWidget::event (this=0x21e8e00, event=0x7fffffffa4a0)
at kernel/qwidget.cpp:8455
#13 0x00007ffff653b22c in QApplicationPrivate::notify_helper (this=0x15527b0,
receiver=0x21e8e00, e=0x7fffffffa4a0) at kernel/qapplication.cpp:4300
#14 0x00007ffff65416fb in QApplication::notify (this=0x154ffe0,
receiver=0x21e8e00, e=0x7fffffffa4a0) at kernel/qapplication.cpp:4183
#15 0x0000000000c89bbd in lyx::frontend::GuiApplication::notify (
this=0x7fffffff9610, receiver=0x0, event=0x48aca30)
at GuiApplication.cpp:2155
#16 0x00007ffff606806c in QCoreApplication::notifyInternal (this=0x154ffe0,
receiver=0x21e8e00, event=0x7fffffffa4a0)
at kernel/qcoreapplication.cpp:704
#17 0x00007ffff6094d42 in QCoreApplication::sendEvent (this=0x1562a50)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#18 QTimerInfoList::activateTimers (this=0x1562a50)
at kernel/qeventdispatcher_unix.cpp:603
#19 0x00007ffff6091848 in timerSourceDispatch (source=<value optimised out>)
at kernel/qeventdispatcher_glib.cpp:184
#20 idleTimerSourceDispatch (source=<value optimised out>)
at kernel/qeventdispatcher_glib.cpp:231

[Tommaso Cucinotta]

Post by John McCabe-Dansted
Hi, I got the following backtrace. It is not really possible to
manually reproduce (the recipe has 1779 keypresses, see [1]); however,
this looks like a simple Null dereference. At a glance it seems that
the attached patch should fix the problem, and I can no longer
reproduce a crash with the patch applied. Does the patch look OK?

I'm fine with it as a temporary "robustness" patch, but I'd like to
understand where the real bug is. In the last part of your KEYCODE
sequence, I can spot a "\Cq", so the issue may be that we instruct
LyX to exit, then someway some keycode gets delivered and the
findAndReplaceScope() called while the buffer, views, buffer-lists
and similar might not be in a consistent state ?

As the "buf" variable was just changed by the last nextPrevBuffer() call,
it would be helpful at least to know in which case (search scope, one
of buffer, document, open_buffers, all_manuals) we were.

Maybe simply the output of "-dbg find" or "-dbg any" would provide
such info, can you produce that ?

Thanks,

T.

[John McCabe-Dansted]

Post by Tommaso Cucinotta
I'm fine with it as a temporary "robustness" patch, but I'd like to
understand where the real bug is. In the last part of your KEYCODE
sequence, I can spot a "\Cq", so the issue may be that we instruct
LyX to exit, then someway some keycode gets delivered and the
findAndReplaceScope() called while the buffer, views, buffer-lists
and similar might not be in a consistent state ?
As the "buf" variable was just changed by the last nextPrevBuffer() call,
it would be helpful at least to know in which case (search scope, one
of buffer, document, open_buffers, all_manuals) we were.
Maybe simply the output of "-dbg find" or "-dbg any" would provide
such info, can you produce that ?

I haven't been able to reproduce with "-dbg find" yet. With "-dbg any"
I get #7376 instead (http://www.lyx.org/trac/ticket/7376)