msSetPROJ_LIB() not thread-safe

[dmorissette]

It has been reported that msSetPROJ_LIB() causes the following errors in multi-thread environments:

*** glibc detected *** ./../../3liz_dev/mozilla/build/xulrunner/dist/bin/xulrunner-bin: corrupted double-linked list: 0xaeeabf60 *** 

and the backtrace looked like this:

/lib/tls/i686/cmov/libc.so.6[0xb656ca85]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb65704f0]
/home/reluc/mapserver-5.2.0/libmapserver.so(msSetPROJ_LIB+0x48)[0xb1ee03b8]
/home/reluc/mapserver-5.2.0/libmapserver.so(msApplyMapConfigOptions+0x4d)[0xb1f945ad] 

Unfortunately I could not reproduce this myself and run it in a debugger, but looking at the code, I see that msSetPROJ_LIB() and msProjFinder() use globals that are not thread-safe:

static char *ms_proj_lib = NULL;
static char *last_filename = NULL;

In a multi-thread environment, msSetPROJ_LIB() may very well free() the value of ms_proj_lib or last_filename that was previously allocated by another thread and that would explain the errors that were reported.

The fix will be to maintain per-thread instances of ms_proj_lib and last_filename in a similar way to what we do to handle the error stack per thread in maperror.c.

[dmorissette]

It seems that it is possible to reproduce this bug using TileCache in multithread mode as well.

[warmerdam]

I have committed a change to msSetPROJ_LIB() to acquire the TLOCK_PROJ lock to avoid race conditions in trunk (r8022). I have not tested the change.

[aboudreault]

Here's patch. It works in the same way that the error stack.

[aboudreault]

For the moment, we'll keep the patch made by Frank in r8022 and close the ticket. If anyone ever raises the need for multiple PROJ_LIBs then we can always apply it at that time.

Note: msResetProjList() should be renamed msFreeProjInfo() if this patch is a day applied.

[dmorissette]

BTW, the reason why the patch has not been applied is that Frank confirmed that cross-thread memory allocation/deallocation is not an issue on any system he has worked on, and he also convinced us that there is not much utility in working with multiple sets of PROJ init files on a single server, so the multiple/different PROJ_LIB value per thread is not a use case that we need to support in practice.