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.

Am 12.07.2012 10:11 schrieb "Mark Morgan Lloyd" <

: 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.

As you said sparc-solaris is a minority target so it would be very helpful if you could test with trunk as well. If the problem does not appear there you could ask whether the fixes could be merged back. Otherwise you report a bug for 2.7.1 and then ask to merge it back once that is fixed. Though it's likely that your help will be required because of the seldomness of your target.

Regards,
Sven

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?

Ludo

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.

Hi,

Not sure if it applies to your case, but afaik SPARC requires natural alignment for memory accesses. "buffer" is not aligned to 8 bytes here... (0xfa5f00bc <---)

Thomas

Although it's OK on Linux. However that pint64() could be relevant.

Thomas Schatzl wrote on Thu, 12 Jul 2012:

We only support 32 bit SPARC, and there we split a 64 bit load into two 32 bit loads. dbl, assuming it points to a double, should point to a 64 bit-aligned memory location though (depending on the cpu, 32 bit alignment may be sufficient, but better be safe than sorry).

Jonas

I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK. Is the if FIntegerDatetimes then something Solaris-specific Ludo?)?

Mark Morgan Lloyd wrote on Thu, 12 Jul 2012:

I'll try to test against 2.7.1 later in the day, although as I've said Linux is OK.

The memory layout is not necessarily the same on both OSes.

Is the if FIntegerDatetimes then something Solaris-specific Ludo?)?

That would be extremely unlikely.

Jonas

In our previous episode, Jonas Maebe said:

Or does the linux kernel contain a facility to work around certain kinds of exceptions?

E.g. IIRC linux recovered float loading alignment problem automatically for PPC 603, and netbsd didn't.

No, the value is read from the server and depends on how the server was compiled. Run 'show integer_datetimes;' in psql or whatever client you are using to see the value.
Pqconnection has detected that it is 'on' on your server. You can check with above command to see if the server agrees with that. With integer_datetimes on the datetime is returned as an int64 with the number of microseconds since 2000-01-01 00:00:00 UTC, hence the dbl^ := pint64(buffer)^/1000000;
Dbl is a Pdouble, so the alignment problem could indeed come from there. The buffer returned by the driver is correct because just before you have pint64(buffer)^ := BEtoN(pint64(CurrBuff)^); CurrBuff being the pointer returned.

Now, you are getting a SIGSEGV, not a SIGBUS which is what you would get for an alignment problem.

Ludo

Agreed, returns 'on'.

[Nod], understood. Hit a slight snag here with trunk FPC + trunk Lazarus:

Target OS: Solaris for SPARC
Compiling sqldblaz.pas
Compiling registersqldb.pas
registersqldb.pas(58,3) Fatal: Can't find unit ibconnection used by registersqldb
Fatal: Compilation aborted
make[2]: *** [sqldblaz.ppu] Error 1
make[2]: Leaving directory
`/export/home/local-share/lazarus-trunk/components/sqldb' make[1]: *** [bigide] Error 2
make[1]: Leaving directory
`/export/home/local-share/lazarus-trunk/components' make: *** [bigidecomponents] Error 2
-bash-3.00$ svn up
At revision 37922.

Anybody got any quick suggestions? "all" builds OK but I presume I need "bigide" because I've used the TQuery etc. on the form.

Still getting this at FPC 21919 and Laz 37954: can anybody recommend a quick hack as a workaround, or do I Mantis it?

I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense to compile in firebird support on that platform.

Remove the ibconnection unit or put it in an {$IFNDEF SOLARIS}. (or should that be SUNOS ?)

You'll have to remove TIBConnection from the registercomponents call as well.

If that works, we'll put it in the sources in SVN.

Michael.

I don't think Firebird works on Solaris or SPARC cpus, so it makes no sense to compile in firebird support on that platform.

Wrong!

From the Firebird website: "Firebird 2.5 runs on Windows (32- and

64-bit), various Linux versions (32- and 64- bit), Solaris (Sparc and Intel), HP-UX (PA-Risc) and MacOS X. Main development is done on Windows and Linux, so new releases are usually offered first for these platforms, followed by other platforms after a few weeks."

---- http://www.firebirdsql.org/en/downloads/

Yep, and there's a 2.1.4 download at
http://www.firebirdsql.org/en/news/firebird-2-1-4-builds-for-solaris-intel-x86-32-and-64-bits-available-12615/

Hi,

Reinier Olislagers wrote

> Yep, and there's a 2.1.4 download at http://www.firebirdsql.org/en/news/firebird-2-1-4-builds-for-solaris-intel-x86-32-and-64-bits-available-12615/

On a side note:
My quoted paragraph doesn't mention FreeBSD, but I have successfully ran Firebird Server & clients under FreeBSD 9.0 on x86, and there are FreeBSD downloads on the Firebird website for 2.1.x and older. So just because the latest version doesn't contain a download for a specific OS+CPU, doesn't make it "not supported". Firebird rocks! :)

That means we should compile & distribute IBase and ibconnection in FPC, because I think currently they are not.

Michael.

On a Solaris SPARC system, looking at /usr/local/lib/fpc,

-bash-3.00$ find . -name ibconnection.ppu |sort
./2.4.2/units/sparc-solaris/fcl-db/ibconnection.ppu ./2.4.4/units/sparc-solaris/fcl-db/ibconnection.ppu ./2.6.0/units/sparc-solaris/fcl-db/ibconnection.ppu

i.e. it's in 2.6.1 but isn't being built in 2.7.1 (trunk). I'm assuming that I need the latter because of code generator fixes that I know were applied.

It would certainly be useful for me to have the /client/ stuff on as many platforms as possible, since I'm starting to look at a large distributed project which will primarily be using PostgreSQL as its backend but I also want the option of Firebird for "leaf" systems.

Obviously the availability of the Firebird /server/ stuff is a completely different issue. I'd neither be surprised nor particularly sorry if that turned out to be x86-only.

Yes.

Apparently, it is available for your platform too.

Strange that it was removed from trunk, though. We'll need to re-enable it. Maybe it is the switch to fpmake that caused this.

Michael.

In our previous episode, said:

It can also be that the change was somehow not properly merged to 2.6.1. Remeber that is all manual fpmake to makefile.fpc translation.

I think I see the problem: it looks as though somebody has left TIBConnection registration right at the end in (Lazarus's) RegisterUnitSQLdb without any conditional around it, possibly to avoid working out the commas :-)

It might be easiest if somebody could get the unit back into FPC- I can check it compiles immediately, and should be able to run it in anger within a couple of weeks.

<snip>

> i.e. it's in 2.6.1 but isn't being built in 2.7.1 (trunk).

<snip>

Not sure if this is where I should be looking but: Trunk
\packages\fcl-db
SqldbConnectionOSes =
[beos,haiku,linux,freebsd,win32,win64,wince,darwin,iphonesim,netbsd,openbsd,aix]; SqldbWithoutPostgresOSes = [win64];

Mmmm... no solaris in there?!? Suggesting no PostgreSQL, Interbase at all for solaris in trunk!??!

later on
P.SourcePath.Add('src/sqldb/postgres',
SqldbConnectionOSes-SqldbWithoutPostgresOSes);
and
P.SourcePath.Add('src/sqldb/interbase', SqldbConnectionOSes); ... suggesting that if you have postgresql, you should have interbase/firebird (except on windows64)

Patch attached that adds solaris to SQLDBConnectionOSes [3], but no idea if it fixes the issue... and if the resulting additional database drivers/code, e.g.:
examples
src/sqldb/mysql
src/sqldb/odbc
would be correct

Note: FreeTDS can probably also be built for Solaris [1]; an older binary release for both Solaris and x86 indicates it must at least have been possible [2]
If so, adding this makes sense in order to get Sybase ASE and MS SQL Server support (the latter obviously client-only). Even if you don't have freetds, compiling the mssqlconn unit won't hurt, I'd think.

Also:
- cleaned up throwing in Oracle with PostgreSQL: separated constant
- sorted constants lines so it's easier to see what OSes get what
- added mssqlconn support (added solaris to MSSQLOSes)
- merged
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes); P.SourcePath.Add('src/sqldb/sqlite', SqliteOSes);
into
P.SourcePath.Add('src/sqldb/sqlite', SqldbConnectionOSes+SqliteOSes); for clarity on who gets sqlite

Question: shouldn't this line
P.SourcePath.Add('src/dbase');
be changed into
P.SourcePath.Add('src/dbase', DBaseOSes);
or do other units also depend on code in src/dbase

[1]
http://stackoverflow.com/questions/704631/access-sql-server-from-solaris [2]
http://www.ibiblio.org/pub/packages/solaris/sparc/ [3]
Both original (DOS EOL) and Unix line ending versions

I enclosed it in sqldb in IFNDEF Solaris.

Mattias

Whoopsie, error in the patch: this:

wasn't true... I had mixed some very similar but different paths. New patches attached.

FPC trunk compiles for me with this patch (x86) on Windows.

Sorry,
Reinier

In Solaris/SPARC,

..
Assembling oracleconnection
Compiling ./fcl-db/src/sqldb/postgres/pqconnection.pp Writing Resource String Table file: pqconnection.rst Assembling pqconnection
Compiling ./fcl-db/src/sqldb/postgres/pqeventmonitor.pp Writing Resource String Table file: pqeventmonitor.rst Assembling pqeventmonitor
Compiling ./fcl-db/src/sqldb/mssql/mssqlconn.pp
mssqlconn.pp(43,3) Fatal: Can't find unit dblib used by mssqlconn Fatal: Compilation aborted

gmake[2]: *** [all] Error 1
gmake[2]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc/packages' gmake[1]: *** [packages_all] Error 2
gmake[1]: Leaving directory
`/export/home/local-src/fpc/fpcbuild-2.7.1/fpcsrc' gmake: *** [build-stamp.sparc-solaris] Error 2

Have I missed any stages out: applied patch successfully, make distclean, make all?

Blast, I'm sorry... missed the dblib unit that is required for FreeTDS...:

which requires adding solaris: from

  DBLibOSes         = [linux,freebsd,netbsd,openbsd,win32,win64,haiku];

to
DBLibOSes =
[linux,freebsd,netbsd,openbsd,solaris,win32,win64,haiku];

Going to have a look at Oracle and mysql units as well then. Mysql: looked at packages\mysql; no idea what if anything to change there.

Oracle packages\oracle\fpmake.pp shows
P.OSes := AllUnixOSes+AllWindowsOSes-[qnx];
which sounds reasonable, so no changes
Likewise for packages\ODBC
Likewise for packages\ibase (Interbase/Firebird)
Likewise for packages\postgres
Likewise for packages\sqlite

Updated patch attached

Hope this one does the trick...

Regards,
Reinier

Please don't apologise: I very much appreciate the effort :-)

That compiles and installs OK. Currently working on Lazarus... bigide compiles and runs OK. Deo volente, I'll get back onto testing the program that was having trouble with PostgreSQL in the morning, after that it will be at least a few days before I've got Borg-NG talking to its backends.

This problem no longer exists in 2.7.1 (21919 + Reinier's solarisdbtrunk2.diff).

However, I've got an "unknown fieldtype" which I'll investigate and if necessary raise separately.

Then it might be good if you report this in Mantis together with Reinier's patch so that it isn't forgotten.

Regards,
Sven

I'll do that, but first I'm working through another odd issue to determine whether it's down to Lazarus on Solaris or is a recently-introduced problem in 2.7.1 targeting SPARC.

Submitted as 22459. There are other database problems affecting SPARC on both Solaris and Linux, I don't know yet what other architectures are affected and suspect it's something to do with Lazarus components or resource handling so will raise it elsewhere.

I've added a description of the patch for clarification.

Thanks Mark!
(Looking askance at my Opensolaris 10 VM gathering dust...)