Bug#454212: megahal segfaults as soon as it's launched
Hello,
* Niko Tyni [Wed, Feb 13, 2008 at 11:08:12AM +0200]:
> On Mon, Feb 11, 2008 at 10:18:37AM +0000, Neil McGovern wrote:
> > Niko Tyni wrote:
> > >>Confirmed using etch i386 (though an amd64 processor). Attached output
> > >>of megahal and strace.
> > >
> > >The attached patch fixes a stack corruption issue on 64-bit architectures
> > >(reading 8 bytes into a 4-byte buffer) and an off-by-one sprintf overflow
> > >in the error and status file name initialization code.
>
> > Confirmed that this patch fixes the issue, at least on the version in Etch.
> >
> > This issue probably qualifies for a stable point update (-release in
> > cc). I can prepare a package if you want.
>
> Just a clarification: I'm not the megahal maintainer, and in fact Laurent
> Fousse recently orphaned it. I'm only interested in megahal because of
> #463146, related to the future Perl 5.10 transition.
> Cc'ing Laurent, as he still seems somewhat interested and was probably
> out of the loop wrt. the patch.
Yup, I missed the mail. Thanks Niko for Cc'ing me. And for the patch,
of course.
> No opinion on the stable update, but I suppose I could prepare a QA
> upload to sid myself if nobody steps up and adopts this...
I don't have my GPG key at work, so it will have to wait for this
evening. If you have a package ready go ahead.
The reason I orphaned megahal is because I read its code too much for
my own good recently. If it weren't for users I'd suggest removal :-)
Over the time megahal has acquired a number of extension I seldom, if
ever, used. It would be best if megahal was team-maintained by people
who actually care about a Tcl, Python, and Perl module (and are
willing to cope with the C codebase too).
I've more or less given up. Markovian models are not hard to code
properly, and I've just done that for a spam filter I consider
including in debian. Writing a megahal replacement from that is just a
matter of providing python bindings.
Regards,
Laurent.
Reply to: