Bug#412782: rekall: rekall crashes when using the create new db wizard

[Steve Langasek <vorlon@debian.org>]

On Tue, Feb 27, 2007 at 10:39:50PM -0600, Sebastian P. Luque wrote:

> I choose "store in database" and rekall crashes immediately after choosing
> the type of database, no matter what it is (mysql, postgresql, the two I
> use in my system).  I get these message at the terminal (narrowed to what
> I think are the relevant lines):

Here's an actual backtrace for this crash, reproducible on both i386 and
amd64:

#0  0x00002aed87dd9a6d in _el_newvar (name=0x7129b0 "print") at syn.cpp:630
#1  0x00002aed87dde434 in el_yyparse () at el.y:397
#2  0x00002aed87dd9754 in el_compile (srce=<value optimized out>, dest=0x0, 
    ifd=0x0, 
    sstr=0x7112f0 "global print ; public f (page) { \n        local dbtype =
    page.ctrl(\"dbType\") ;\nprint (dbtype.value() + \"\\n\") ;\n        if
    (dbtype.value() == \"xbase\") return \"xbase\" ; \n        return
    (dbtype.attr(\"fla"..., 
    eout=<value optimized out>) at compile.cpp:94
#3  0x00002aed87c21135 in KBWizardPage::compile (this=<value optimized out>, 
    name=@0x7fff23623ba0) at kb_wizardbits.cpp:978
#4  0x00002aed87c21221 in KBWizardPage::nextPage (this=0x6a4300)
    at kb_wizardbits.cpp:1110
#5  0x00002aed87c2d2b8 in KBWizard::clickNext (this=0x7fff23624cd0)
    at kb_wizard.cpp:598
#6  0x00002aed87c1f458 in KBWizard::qt_invoke (this=0x7fff23624cd0, _id=52, 
    _o=0x7fff23623d20) at kb_wizard.moc:399
#7  0x00002aed8a472c26 in QObject::activate_signal ()
   from /usr/lib/libqt-mt.so.3
#8  0x00002aed8a4737b6 in QObject::activate_signal ()
   from /usr/lib/libqt-mt.so.3
#9  0x00002aed8a7e82bf in QButton::clicked () from /usr/lib/libqt-mt.so.3
#10 0x00002aed8a50cbd7 in QButton::mouseReleaseEvent ()
   from /usr/lib/libqt-mt.so.3
[...]

Line 630 is:

630             if ((nptr = lookup (name, cblk->val.block.vars)) == NULL)

This is a dereference of a null pointer, cblk.

cblk is a global variable which is only initialized in the function
_el_newblk(), and cleared in el_syn_clean().  There appear to be two bugs
here: first, that _el_newblk() hasn't been called, second, that this results
in a NULL deref instead of catching the problem sanely.

I'm not even sure what the scripting language being used here is, though, so
I have no idea what causes the first bug.

As this package is currently orphaned, I'd suggest dropping it from the
release given that this most basic operation doesn't work and a fix seems
unlikely.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/