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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: emre(at)hasegeli(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #11770: Segfault on spell.c when there are more than one characters as suffix flag
Date: 2014-10-23 16:28:16
Message-ID: 5849.1414081696@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

emre(at)hasegeli(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Joe Van Dyk 2014-10-23 18:59:12 ltree::text not immutable?
Previous Message chocholousp 2014-10-23 15:38:16 BUG #11771: wrong behaviour of planner when pushing conditions