BUG #6185: Segmentation fault with NULL string columns

On 30.08.2011 11:51, Isaac Jurado wrote:

The following bug has been logged online:

Bug reference: 6185
Logged by: Isaac Jurado
Email address: ijurado@econcept.es
PostgreSQL version: 8.4.8
Operating system: Ubuntu 10.04.03 LTS (x86_64)
Description: Segmentation fault with NULL string columns
Details:

Here's the script to make it fail:

CREATE DATABASE killme;
\c killme
CREATE FUNCTION to_ascii(bytea, name) RETURNS text AS 'to_ascii_encname'
LANGUAGE internal;
CREATE TABLE mytable (id INTEGER PRIMARY KEY, mytext TEXT);
INSERT INTO mytable (id, mytext) VALUES (1, '');
SELECT * FROM mytable WHERE to_ascii(convert_to(mytext, 'latin1'), 'latin1')
= to_ascii(convert_to('nicetry', 'latin1'), 'latin1');
UPDATE mytable SET mytext=NULL WHERE id=1;
SELECT * FROM mytable WHERE to_ascii(convert_to(mytext, 'latin1'), 'latin1')
= to_ascii(convert_to('nicetry', 'latin1'), 'latin1');

After the second query, the database server segfaults. Note that it only
fails for NULL values. The to_ascii/convert_to combination is a recipe for
diacritics elimination found on a PostgreSQL forum.

to_ascii_encname is marked as STRICT, which means that it returns NULL
on NULL input, without ever calling the underlying C function. The
"to_ascii" function that you created is not marked as STRICT, so the
to_ascii_encname C function is called on NULL input. It's not prepared
for that, and crashes, because it's not supposed to be called on NULL input.

Why do you create your own 'internal' language function like that in the
first place? Just use the existing to_ascii function.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Excerpts from Isaac Jurado's message of mar ago 30 05:51:55 -0300 2011:

The following bug has been logged online:

Bug reference: 6185
Logged by: Isaac Jurado
Email address: ijurado@econcept.es
PostgreSQL version: 8.4.8
Operating system: Ubuntu 10.04.03 LTS (x86_64)
Description: Segmentation fault with NULL string columns
Details:

Here's the script to make it fail:

CREATE DATABASE killme;
\c killme
CREATE FUNCTION to_ascii(bytea, name) RETURNS text AS 'to_ascii_encname'
LANGUAGE internal;

Seems you neglected to mark the function STRICT.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

On Tue, Aug 30, 2011 at 8:21 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:

to_ascii_encname is marked as STRICT, which means that it returns NULL
on NULL input, without ever calling the underlying C function. The
"to_ascii" function that you created is not marked as STRICT, so the
to_ascii_encname C function is called on NULL input. It's not prepared
for that, and crashes, because it's not supposed to be called on NULL
input.

I figured that 5 minutes after reporting. I tried to sent a reply email
but it seems it didn't arrive. Thanks anyway.

Why do you create your own 'internal' language function like that in
the first place? Just use the existing to_ascii function.

The default to_ascii expects a string as a first argument. As our DB
encoding is UTF8 we need to filter everything through
convert_to(..., 'LATIN1'). Because convert_to function returns a
"bytea" type, we cannot use to_ascii in vanilla flavour.

We are not too fond with the PostgreSQL specifics (although the explicit
::text cast didn't work), so we found that function definition on a
wiki and it worked.

But now, unless you know a more correct way to do it, it works like a
charm by appending "STRICT" to the function definition.

Best regards and sorry for the noise.

--
Isaac Jurado
Internet Busines Solutions eConcept

On Tue, Aug 30, 2011 at 8:22 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:

Seems you neglected to mark the function STRICT.

Yes, that was it. Sorry for the invalid bug report.

Best regards.

--
Isaac Jurado
Internet Busines Solutions eConcept