[MAPSERVER-USERS] msProcessProjection(): Projection library error.

[Frank Warmerdam]

Tamas Szekeres wrote:
> Frank,
> 
> I think this issue might be originated to a missing lock around the
> static pj_errno in the proj library. Apparently the 'no system list'
> indicates an invalid error code that is: an invalid actual value of
> pj_errno. I guess the code below may run against another pj invocation
> that is not locked.

Tamas,

The "no system list" message just means that PROJ was built without support
for strerror() - that is HAVE_STRERROR was not defined in the configure.
This seems to happen almost all the time (perhaps a problem in the proj
configure).

	char *
pj_strerrno(int err)
{
     static char note[50];

     if (err > 0)
#ifdef HAVE_STRERROR
         return strerror(err);
#else
     {
         sprintf(note,"no system list, errno: %d\n", err);
         return note;
     }
#endif
     else if (err < 0) {
         int adjusted_err = - err - 1;
         if (adjusted_err < (sizeof(pj_err_list) / sizeof(char *)))
             return(pj_err_list[adjusted_err]);
         else
         {
             sprintf( note, "invalid projection system error (%d)",
                      err );
             return note;
         }
     } else
         return NULL;
}

It *is* possible that there is a missing lock around some MapServer
call to PROJ.4 and some other thread ends up setting pj_errno and
it confuses pj_init() in another thread resulting in pj_init() returning
NULL.  I see that pj_init ends with:

	/* projection specific initialization */
	if (!(PIN = (*proj)(PIN)) || errno || pj_errno) {
bum_call: /* cleanup error return */
		if (!pj_errno)
			pj_errno = errno;
		if (PIN)
			pj_free(PIN);
		else
			for ( ; start; start = curr) {
				curr = start->next;
				pj_dalloc(start);
			}
		PIN = 0;
	}

So, something other than pj_init() setting pj_errno could result
in an unexpected failure of pj_init().  If this is the issue, it would
require a careful audit of PROJ.4 calls in MapServer, searching for one
that is unprojected by the TLOCK_PROJ lock.

Hmm, reviewing the PROJ.4 calls from MapServer I'm rather astounded to
discover that while pj_init() is projected by the TLOCK_PROJ, calls to
pj_transform() are not!   I assume I did this initially because I assumed
that the major thread safety risks were in pj_init(), but clearly
pj_transform() can also set pj_errno, and in fact there are issues in
pj_transform() with loading of datum shift files.

Hmmm.  I suspect we ought to rework things in mapserver to project all
pj_transform() calls with the lock.   I would appreciate it if someone could
file a ticket on this issue, and assign it to me.  I'd be willing to make
these changes in trunk if someone (ie. Rich!) who is running into problems
could test the changes in a situatio nwhere these problems were being
encountered.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org