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]
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
