Re: BUG #11770: Segfault on spell.c when there are more than one characters as suffix flag - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #11770: Segfault on spell.c when there are more than one characters as suffix flag
Date
Msg-id 5849.1414081696@sss.pgh.pa.us
Whole thread Raw
In response to BUG #11770: Segfault on spell.c when there are more than one characters as suffix flag  (emre@hasegeli.com)
List pgsql-bugs
emre@hasegeli.com writes:
> How to reproduce:
> ...
> Note that the affix file is not correct without "FLAG num" which is not
> supported by PostgreSQL.  Also, the code fails to report the proper error
> on spell.c:673 when "FLAG num" is used.

Hmm.  The immediate cause of the crash is that the code is expecting some
"CompoundAffix"es to exist when usecompound = true, but they don't.
I'm not sure whether we should flag the affix file as invalid, but in
any case it'd be a good idea for CheckCompoundAffixes to defend itself
against *ptr being NULL.

As for whether the error is proper ... this code is woefully
underdocumented, but it looks to me like NIImportAffixes() is designed
to import the original ispell affix file format, and if it decides that
the file is not that but MySpell/Hunspell format then it sends control
off to NIImportOOAffixes to re-parse the whole thing.  The difficulty
is that FLAG commands exist in both formats and it's not being careful
about whether the FLAG command is new or old format.  Probably we should
insist that the FLAG argument not contain multiple letters in order to
deem it old format.

            regards, tom lane

pgsql-bugs by date:

Previous
From: emre@hasegeli.com
Date:
Subject: BUG #11770: Segfault on spell.c when there are more than one characters as suffix flag
Next
From: Casey & Gina
Date:
Subject: Re: BUG #11638: Transaction safety fails when constraints are dropped and analyze is done