-
Notifications
You must be signed in to change notification settings - Fork 786
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
setlocale as used inside pj_init_ctx is not threadsafe #226
Comments
Comment by warmerdam on 20 Oct 2013 18:09 UTC
So it seems that the old locale is copied with strdup() rather than assuming the internal string will last indefinately. Does that not mitigate the problem? Are you using this version? (I realize there is still a race condition, but it seems this would not hit often, and we could put a lock around it). I'm a bit hesitant to put in the proposed code change partly because it is quite rude of a sublibrary like PROJ.4 to change whether or not locales are per-thread. Certainly applications running into this problem could do it in advance. |
Comment by whodevelopment on 13 Nov 2013 12:42 UTC IMHO it is even more rude for a sublibrary to change the locale using setlocale in the first place. On posix systems uselocale can be used for thread-local locales, on windows benharper's suggestion (Or just write a floating-point parser). Also "Putting a lock around" it is no fix for the problem: it would require any code that even reads the locale to acquire that lock (ie. also code in other libraries). Regards, See: |
I haven't found the reason, why this problem is triggered on some machines and not on others (with basically the same setup - at least regarding locale and number format), but I've found two ways to work around it: @ 1. is a bit brute force and doesn't seem to be appropriate and I think, I was just lucky to not experience any side effects, as the faq states: @ 2. was inspired by the comment of user
The solution could be, to check for VS version (<2012 and >=2012) and then either call |
Aouch about the differences in behaviours between VS versions ! It seems to me that this is completely unspecified behaviour and might change again in the next releases. I'd rather see 2 other solutions :
Although it will require editing more files, I'd rather favor the local insensitive atof() approach |
👍
Oh, interesting, I also had tried |
Remove setlocale() use in pj_init_ctx(), and replace uses of atof() & strtod() by their locale safe variants pj_atof() and pj_strtod(). Proj versions from now advertize #define PJ_LOCALE_SAFE 1 in proj_api.h and export pj_atof() & pj_strtod()
Remove setlocale() use in pj_init_ctx(), and replace uses of atof() & strtod() by their locale safe variants pj_atof() and pj_strtod(). Proj versions from now advertize #define PJ_LOCALE_SAFE 1 in proj_api.h and export pj_atof() & pj_strtod()
…t is locale safe (i.e. with fix for OSGeo/PROJ#226) git-svn-id: https://svn.osgeo.org/gdal/trunk/gdal@29493 f0d54148-0727-0410-94bb-9a71ac55c965
Reported by benharper on 4 Oct 2013 15:17 UTC
setlocale is used inside pj_init_ctx, but this is not thread safe.
I have not seen this to be a problem until upgrading to Visual Studio 2012, where it does manifest in heap corruption.
Possible solutions that I can think of:
if defined(_MSC_VER) && _MSC_VER >= 1700
/* You must use _configthreadlocale(_ENABLE_PER_THREAD_LOCALE)
to ensure that each thread has its own locale, otherwise
this function will cause heap corruption if called from
multiple threads. */
if (_configthreadlocale(0) != _ENABLE_PER_THREAD_LOCALE) {
pj_ctx_set_errno(ctx, PJ_THREAD_LOCALE_RACE);
goto bum_call;
}
Migrated-From: https://trac.osgeo.org/proj/ticket/226
The text was updated successfully, but these errors were encountered: