Re: selfmade datatype in C and server-crash

On Wednesday 05 October 2005 05:01, Tom Lane wrote:
> Markus Schulz <msc(at)antzsystem(dot)de> writes:
> > This works fine and then i've created the new Type like:
> >
> > CREATE OR REPLACE FUNCTION etextin(cstring)
> > RETURNS etext AS
> > '$libdir/new_types.so', 'etextin'
> > LANGUAGE 'c' VOLATILE;
> >
> > CREATE OR REPLACE FUNCTION etextout(etext)
> > RETURNS cstring AS
> > '$libdir/new_types.so', 'etextout'
> > LANGUAGE 'c' VOLATILE;
>
> You'd likely be well advised to declare these STRICT (hint: is the C
> code checking for null input?) ... and unless the datatype has weird

no, was'nt checked. copy from original text code.

> semantics, its I/O functions should be IMMUTABLE. This doesn't
> matter too much for the system's ordinary use of I/O functions, but
> for security you want to make sure the functions are properly marked
> in case they get called directly.

ok, changed to strict (makes really sense), but don't change anything.
now there is no need for NULL checks if i understand right?

> > But if i'm trying to use the type in a table (for instance table
> > with only one etext column) the server crashed after inserting the
> > second (first insert works) tuple or on every select.
>
> Getting a stack trace from the crash would be helpful. But the fact
> that it only fails on the second try makes me suspicious that it's
> a memory-management issue. Count thy pallocs.

here's a backtrace.

Program received signal SIGSEGV, Segmentation fault.
0x402eacff in strlen () from /lib/libc.so.6
(gdb) sharedlibrary new_types
Reading symbols from /usr/lib/postgresql/lib/new_types.so...done.
Loaded symbols for /usr/lib/postgresql/lib/new_types.so
(gdb) bt
#0 0x402eacff in strlen () from /lib/libc.so.6
#1 0x40ffeb00 in etextin (fcinfo=0x0) at new_types.c:27
#2 0x081ec020 in fmgr_internal_function ()
#3 0x081ed720 in OidFunctionCall3 ()
#4 0x080d0ec2 in stringTypeDatum ()
#5 0x080d1745 in coerce_type ()
#6 0x080d130b in coerce_to_target_type ()
#7 0x080d351e in updateTargetListEntry ()
#8 0x080b1549 in parse_sub_analyze ()
#9 0x080b0fe6 in parse_sub_analyze ()
#10 0x080b0de9 in parse_sub_analyze ()
#11 0x080b0cd9 in parse_analyze ()
#12 0x0817c7c1 in pg_analyze_and_rewrite ()
#13 0x0817cb88 in pg_plan_queries ()
#14 0x0817f1e0 in PostgresMain ()
#15 0x08158d7b in ClosePostmasterPorts ()
#16 0x08158763 in ClosePostmasterPorts ()
#17 0x08156c68 in PostmasterMain ()
#18 0x081562f9 in PostmasterMain ()
#19 0x08126266 in main ()

my test query was:(run twice and crashed on second run)
insert into test ( var1) values ('andf');

the table has only one column of type etext.

in my opinion there must be already something wrong in first "insert"
statement and then perhaps the heap became corrupt?
if i understand strict correctly, there is no chance to got a NULL
Pointer into strlen?!?

here is the etextin code:(cut'n'paste from adt/varlena.c Code)

Datum
etextin(PG_FUNCTION_ARGS)
{
char *inputText = PG_GETARG_CSTRING(0);
text *result;
int len=0;

/* verify encoding */
len = strlen(inputText);
pg_verifymbstr(inputText, len, false);

result = (text *) palloc(len + VARHDRSZ);
VARATT_SIZEP(result) = len + VARHDRSZ;

memcpy(VARDATA(result), inputText, len);

PG_RETURN_TEXT_P(result);
}

compiled and linked like:
gcc -Wall -g -O2 -I. -I/usr/include/postgresql/server -c -o
new_types.o new_types.c
gcc -shared new_types.o -lm -o new_types.so

Markus Schulz