compiled C function for postgresql fails (64-bit only)

[cassiope]

I have a function that I've used since early postgres-7.x days.  Now migrating to a 64-bit
(i7) machine - running 2.6.30/'squeeze' with postgresql-8.4.1-1.  This function is a simple
one that takes a string representation of a number as its sole argument (engineering
notation), and returns the number.  The floating point value that it returns is the same
value {6.94822224692498e-310} with every call, even when the string changes.
  The same function works perfectly on a separate 2.6.30/'squeeze' system, PG-8.4.1-1,
that is a 32-bit system - just like it has on previous postgres versions.
  If I enable a diagnostic mid-functon dump-to-a-file, I can see that the function
is receiving its input and computing the output properly - it's "just" a matter of
getting the output translated into sql-land.  This is with the "Version 0" calling
conventions, with a return type of float8* .  Attempting "Version 1" calling conventions
on the 64-bit system has not yet been successful - I haven't yet been able to avoid a client
segfault, whether I use a stack variable for the float8 result, or use palloc().

  In case it would help, the key parts of the function are:


float8 *sick_fct(const char *strng)
{
    float8 *result;
    char stack_string_buffer[BIG_STRING_SPACE];

  // string copy operation : strng -> stack_string_buffer
  ...

  result= (float8*)palloc(sizeof(float8));
  *result= inner_conversion_function(stack_string_buffer);
  // printing this *result to a file shows that the conversion is correct
  // the mysteriously wrong part seems to be:
  return result;
}

I'm compiling it as:
  g++-4.3 -c -I/usr/include -I/usr/lib/gcc/x86_64-linux-gnu/4.3/include -Wall -Wshadow -Wpointer-arith -Wcast-align -I/usr/include/postgresql -I(yet more includes) -fPIC -x c  sick_fct.c -o sick_fct.o

and building the library as:
  g++-4.3 -shared -Wl,-soname,lib_sickfct.so.1 -o lib_sickfct.so.1.0 *.o

and "creating" the function within PG as:
  CREATE OR REPLACE FUNCTION sick_fct(text) RETURNS float
   AS '/lib-path/lib_sickfct', 'sick_fct' LANGUAGE C STRICT;

Note that changing the "float" on the last line to "double precision" changes nothing.

  Odds are that I'm doing something stupid, but so far I haven't figured out
what it is.  Thanks for any insights you might have!

  -f


--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Boyd Stephen Smith Jr.-3]

I don't see anything Debian-specific with your query, and I doubt there are
that many persons on the list that have the pgSQL experience required to
really dig into this.  You might have better luck consulting the pgsql-general
or pgsql-interfaces list maintained by postgresql.org.

I don't recognize anything wrong with your code off the top of my head, but
I've never had a need to call a C function from SQL, yet.
--
Boyd Stephen Smith Jr.           ,= ,-_-. =.
bss@...             ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/            \_/

[Glyn Astill]

--- On Tue, 3/11/09, Frank Miles <fpm@...> wrote:

>
> I have a function that I've used
> since early postgres-7.x days.  Now migrating to a
> 64-bit
> (i7) machine - running 2.6.30/'squeeze' with
> postgresql-8.4.1-1.  This function is a simple
> one that takes a string representation of a number as its
> sole argument (engineering
> notation), and returns the number.  The floating point
> value that it returns is the same
> value {6.94822224692498e-310} with every call, even when
> the string changes.
>     The same function works perfectly on a
> separate 2.6.30/'squeeze' system, PG-8.4.1-1,
> that is a 32-bit system - just like it has on previous
> postgres versions.
>     If I enable a diagnostic mid-functon
> dump-to-a-file, I can see that the function
> is receiving its input and computing the output properly -
> it's "just" a matter of
> getting the output translated into sql-land.  This is
> with the "Version 0" calling
> conventions, with a return type of float8* . 
> Attempting "Version 1" calling conventions
> on the 64-bit system has not yet been successful - I
> haven't yet been able to avoid a client
> segfault, whether I use a stack variable for the float8
> result, or use palloc().

From the 8.4 release notes:

"Pass float8, int8, and related datatypes by value inside the server on 64-bit platforms (Zoltan Boszormenyi)

Add configure option --disable-float8-byval to use the old behavior. As above, this change might break old-style external C functions."

So it could be a bug, send it to pgsql-general and you'll get a prompt response.





--
To UNSUBSCRIBE, email to debian-user-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...