runtime problems on Solaris

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

runtime problems on Solaris

James Marca
Hi,

I have successfully run postgis 1.0.1 on my workstation/development
box, but now we are having problems getting PostGIS 1.0.1 to run on
our Solaris-based server.

The compile seems to work fine, but any attempt to use the resulting
liblwgeom.so (including running any of the tests in regress) cause the
postgresql server to crash.

for example:

jmarca@trantor:~$ dropdb pgis_test
jmarca@trantor:~$ createdb pgis_test
jmarca@trantor:~$ createlang plpgsql pgis_test
jmarca@trantor:~$ psql -f /testbed/tools/share/postgresql/contrib/lwpostgis.sql pgis_test

(no errors)

jmarca@trantor:~$ psql pgis_test
Welcome to psql 8.0.3, the PostgreSQL interactive terminal.
...
pgis_test=# select 'SRID=32611;LINESTRING(408037 3749164,408040 3749208)'::geometry;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!>

If we do the same using PostGISv0.9 (substituting the old postgis.sql
in the psql line above), the select works as expected (as does
everything else).

We've tried upgrading everything (although geos 2.1.2 came out the day
after we moved to 2.1.1), but nothing has fixed the problem.  

The output of postgis_full_version is
 POSTGIS="1.0.1" GEOS="2.1.1" PROJ="Rel. 4.4.9, 29 Oct 2004" USE_STATS
DBPROC="0.3.0" RELPROC="0.3.0"

And the output of select version() is
 PostgreSQL 8.0.3 on sparc-sun-solaris2.9, compiled by GCC gcc-3.3
 (GCC) 3.3

and uname -a gives

SunOS trantor 5.9 Generic_112233-08 sun4u sparc SUNW,Sun-Fire-280R

At first, we thought it might be a 32 bit/64 bit library problem, but
that doesn't seem to be the case---ldd shows that the library is
linked against only 64 bit libraries, and the debugger seems to show
only 64 bit libraries are being loaded.

We were able to make the db crash while tracing the process and got
this:

27725:  stat("/testbed/tools/lib/libc.so.1", 0xFFFFFFFF7FFF9070) Err#2 ENOENT
27725:  stat("/usr/lib/64/libc.so.1", 0xFFFFFFFF7FFF9070) = 0
27725:  stat("/testbed/tools/lib/sparcv9/libgcc_s.so.1", 0xFFFFFFFF7FFF9070) = 027725:  munmap(0xFFFFFFFF7D300000, 8192)                = 0
27725:  brk(0x10078DAD0)                                = 0
27725:  brk(0x100791AD0)                                = 0
27725:      Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFFFF7E200770
27725:        siginfo: SIGSEGV SEGV_MAPERR addr=0x100792000
27725:      Received signal #11, SIGSEGV [default]
27725:        siginfo: SIGSEGV SEGV_MAPERR addr=0x100792000

Again, using the old libpostgis.so (version 0.9) works fine.

Has anybody else gotten PostGIS 1.0+ to compile and run on Solaris,
and if so, are there any known traps/problems.  Should we try using
the CVS version?  Should we upgrade GCC, and if so, to which version?  

Any advice would be appreciated.  I haven't found much that is
relevant in the mailing list archives (using google).  I would be
happy to provide any other information that might be relevant.

Thanks in advance,
James Marca


_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: runtime problems on Solaris

strk
On Mon, Jun 13, 2005 at 04:52:12PM -0700, James Marca wrote:
...
> At first, we thought it might be a 32 bit/64 bit library problem, but
> that doesn't seem to be the case---ldd shows that the library is
> linked against only 64 bit libraries, and the debugger seems to show
> only 64 bit libraries are being loaded.

I think it can still be a 32/64bit issue

> We were able to make the db crash while tracing the process and got
> this:
>
> 27725:  stat("/testbed/tools/lib/libc.so.1", 0xFFFFFFFF7FFF9070) Err#2 ENOENT
> 27725:  stat("/usr/lib/64/libc.so.1", 0xFFFFFFFF7FFF9070) = 0
> 27725:  stat("/testbed/tools/lib/sparcv9/libgcc_s.so.1", 0xFFFFFFFF7FFF9070) = 027725:  munmap(0xFFFFFFFF7D300000, 8192)                = 0
> 27725:  brk(0x10078DAD0)                                = 0
> 27725:  brk(0x100791AD0)                                = 0
> 27725:      Incurred fault #6, FLTBOUNDS  %pc = 0xFFFFFFFF7E200770
> 27725:        siginfo: SIGSEGV SEGV_MAPERR addr=0x100792000
> 27725:      Received signal #11, SIGSEGV [default]
> 27725:        siginfo: SIGSEGV SEGV_MAPERR addr=0x100792000

mmm... does the trace stop there ?
Can you try a backtrace from gdb ?

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Re: runtime problems on Solaris

James Marca
At approximately Tue, Jun 14, 2005 at 11:04:05AM +0200, [hidden email] wrote:
> mmm... does the trace stop there ?
> Can you try a backtrace from gdb ?

We will try.  My sysadmin was having trouble getting gdb to connect to
the postgresql process to trace the session.  Is there anyway to
run the postgis code *without* using postgresql?

James
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: Re: runtime problems on Solaris

strk
On Tue, Jun 14, 2005 at 10:37:20AM -0700, James Marca wrote:
> At approximately Tue, Jun 14, 2005 at 11:04:05AM +0200, [hidden email] wrote:
> > mmm... does the trace stop there ?
> > Can you try a backtrace from gdb ?
>
> We will try.  My sysadmin was having trouble getting gdb to connect to
> the postgresql process to trace the session.  Is there anyway to
> run the postgis code *without* using postgresql?

No way, you need postgres.
What I do is:

# pg_ctl stop
# gdb postgres
gdb> run test.sql

--strk;
_______________________________________________
postgis-users mailing list
[hidden email]
http://postgis.refractions.net/mailman/listinfo/postgis-users