[fpc-pascal] Database problem on Solaris SPARC

[Mark Morgan Lloyd]

Ludo Brands wrote:
>> I've found a problem when a (well-tested) program that connects to a 
>> PostgreSQL database is compiled and run on Solaris 10 for 
>> SPARC, Linux 
>> SPARC is OK.
>>
>> I appreciate that this is a minority platform, but would I be less 
>> unpopular reporting it against 2.6.0 or testing it against 
>> 2.7.1 first? 
>> Problem appears to be in pqconnection.pp and I can see that it's 
>> recently been worked on.
>>
> AFAIK non of the recent changes in pqconnection.pp would affect solaris
> (alignment or other). So if the program compiled with 2.6.0 works fine on
> linux sparc and fails on solaris sparc I would suspect more the PostgreSQL
> client libraries. Are those the same versions? What problems are you
> experiencing? 

As background, program gets information from a table on a PostgreSQL 
server using 2x query objects in a thread. The current info is then 
copied to foreground LCL components using synchronise. I don't think any 
of this is relevant since it works reliably on Linux on all other 
architectures available to me, doesn't work on Windows for unrelated 
reasons (named pipe issue).

Builds OK on SPARC Solaris 10 using 2.6.0, but on running get a 
consistent error

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 4]
0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, 
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLOB=fa
803               if FIntegerDatetimes then dbl^ := pint64(buffer)^/1000000;
Current language:  auto; currently pascal
(gdb) bt
#0  0x004b08b8 in TPQCONNECTION__LOADFIELD (CURSOR=0xfad601a0, 
FIELDDEF=0xfad30f20, BUFFER=0xfa5f00bc, CREATEBLO
#1  0x004b58c8 in TCUSTOMSQLQUERY__LOADFIELD (FIELDDEF=0xfad30f20, 
BUFFER=0xfa5f00bc, CREATEBLOB=false, this=0xf
#2  0x004ef414 in TCUSTOMBUFDATASET__LOADBUFFER (BUFFER=0xfa5f00bc '', 
this=0xfceb96c0) at bufdataset.pas:1781
#3  0x004eeaec in TCUSTOMBUFDATASET__GETNEXTPACKET (this=0xfceb96c0) at 
bufdataset.pas:1665
#4  0x004edf4c in TCUSTOMBUFDATASET__GETRECORD (BUFFER=0xfa5f04a0 
'����', GETMODE=GMNEXT, DOCHECK=true, this=0xf
#5  0x004c8278 in TDATASET__GETNEXTRECORD (this=0xfceb96c0) at 
dataset.inc:770
#6  0x004c8438 in TDATASET__GETNEXTRECORDS (this=0xfceb96c0) at 
dataset.inc:799
#7  0x004c9744 in TDATASET__RECALCBUFLISTSIZE (this=0xfceb96c0) at 
dataset.inc:1154
#8  0x004c6e14 in TDATASET__DOINTERNALOPEN (this=0xfceb96c0) at 
dataset.inc:411
#9  0x004c8cb0 in TDATASET__OPENCURSOR (INFOQUERY=false, 
this=0xfceb96c0) at dataset.inc:962
#10 0x004c92fc in TDATASET__SETACTIVE (VALUE=true, this=0xfceb96c0) at 
dataset.inc:1087

Those lines are truncated since I've C&Ped from a disconnected ssh 
session. Appears to be this on 2.6.0:

   dbl := pointer(buffer);
   if FIntegerDatetimes then dbl^ := pint64(buffer)^/1000000; // 803

which I think is this on 2.7.1 although I've not tested yet:

   dbl := pointer(buffer);
   if FIntegerDatetimes then
     dbl^ := BEtoN(pint64(CurrBuff)^) / 1000000	// 856
   else

Also I've not tested recently on ARM Linux, but since SPARC Linux is OK 
it's unlikely to be a straight alignment error.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]