Date: Tue, 3 Dec 2019 19:06:53 +0100
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: cilizili@protonmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16144: Segmentation fault on dict_int extension
Message-ID: <20191203180653.dyuopwzpvz2iqz2c@development>
References: <16144-a36a5bef7657047d@postgresql.org>
 <20191202161920.d3k7b6dpqcgl5mst@development>
 <20191203175211.fllaggkccolrngbi@development>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20191203175211.fllaggkccolrngbi@development>
Precedence: bulk

On Tue, Dec 03, 2019 at 06:52:11PM +0100, Tomas Vondra wrote:
>On Mon, Dec 02, 2019 at 05:19:20PM +0100, Tomas Vondra wrote:
>>On Mon, Dec 02, 2019 at 12:41:21PM +0000, PG Bug reporting form wrote:
>>>The following bug has been logged on the website:
>>>
>>>Bug reference:      16144
>>>Logged by:          cili
>>>Email address:      cilizili@protonmail.com
>>>PostgreSQL version: 12.1
>>>Operating system:   CentOS 7.4
>>>Description:
>>>
>>>The dict_int extension is an example of an add-on dictionary template for
>>>full-text search. The 'intdict' is a built-in dictionary. If we set MAXLEN
>>>parameter with negative value for the dictionary, ts_lexize function causes
>>>a segmentation fault. The negative limit for MAXLEN which causes
>>>segmentation fault is environment dependent.
>>>
>>># initdb
>>># pg_ctl -D /var/lib/pgsql/data -l logfile start
>>># psql
>>>
>>>postgres=# CREATE EXTENSION dict_int;
>>>CREATE EXTENSION
>>>postgres=# ALTER TEXT SEARCH DICTIONARY intdict (MAXLEN = -214783648);
>>>ALTER TEXT SEARCH DICTIONARY
>>>postgres=# select ts_lexize('intdict', '12345678');
>>>server closed the connection unexpectedly
>>>	This probably means the server terminated abnormally
>>>	before or while processing the request.
>>>The connection to the server was lost. Attempting reset: Failed.
>>>!>
>>>!>\q
>>>
>>
>>Yeah, this seems to be a failure in evaluating maxlen parameter. It's
>>set to 6 by default, but we simply trust whatever value the user gives
>>us, and then we do this
>>
>>   txt[d->maxlen] = '\0';
>>
>>which fails for obvious reasons.
>>
>>Will fix by rejecting maxlen values less than 1. The docs don't say
>>which value should the the minimum, but 0 seems useless.
>>
>
>I've pushed a fix for this, rejecting maxlen values less than 1. I also
>backpatched this to all supported releases (the issue exists since 9.3).
>

Damn, a silly typo in the commit subject (leat -> least) ... :-/

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services