Potential locking issue in newlocale

[Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>]

Hello,

I'm trying to track down sporadic failures of a libstdc++ test case,
22_locale/locale/cons/12658_thread-1.cc.  The test case is intended to
test thread-safety of the libstdc++ locale routines, but of course
those call through to glibc locale routines.

And in fact, in one crash I have analysed, it looks as if glibc-internal
data structures are corrupted.  Specifically, in the loop

      for (cnt = 0; locale_file->successor[cnt] != NULL; ++cnt)
        {
          if (locale_file->successor[cnt]->decided == 0)
            _nl_load_locale (locale_file->successor[cnt], category);
          if (locale_file->successor[cnt]->data != NULL)
            break;
        }

in _nl_find_locale (locale/findlocale.c),
accessing locale_file->successor[cnt]->data crashed due to a NULL
locale_file->successor[cnt].  As this condition is tested by the loop,
this looks like a thread-safety issue.

Now, I'm wondering what locks are supposed to protect these structures.
It would appear that _nl_find_locale, like _nl_remove_locale, expects
to be called with the __libc_setlocale_lock held.  There is in any case
a comment before _nl_remove_locale (not _nl_find_locale, though) to that
effect.

And indeed the callers of _nl_find_locale in setlocale and
_nl_remove_locale in __freelocale do take that lock.

However the routine __newlocale (locale/newlocale.c) calls both
_nl_find_locale and _nl_remove_locale without taking that lock,
as far as I can tell.

Am I correct in the assumption that this is a bug in newlocale?
Where would be the proper points to take the lock?


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com