Bugzilla

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use more recents of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` that we will report, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform which we will forward.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` that we will report, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform which we will forward.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` that we will report, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::_S_initialize` through `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform which we will forward.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` that we will report, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `liblgpllibs.so`'s `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::_S_initialize` through `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform which we will forward.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` that we will report, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `liblgpllibs.so`'s `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::_S_initialize` through `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions, which we will forward, about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++`, which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `liblgpllibs.so`'s `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::_S_initialize` through `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions, which we will forward, about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform.

We have made good progress with [:sergesanspaille]. The crash is likely caused by the use of the `-static-libstdc++` in these builds of Firefox, which [:sergesanspaille] suggests could have been introduced initially [because of a need to use a more recent version of `libstdc++` than available on the platform](https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1856861).

The root cause here seems to be a bug in `libstdc++` [1], which occurs when using `-static-libstdc++` to compile a main executable and to compile a dynamically loaded library if both make use of `std::locale` code that reaches `std::locale::_S_initialize`. The main executable and the shared library will each have their own instance of the local `c_locale` buffer (declared in `locale_init.cc` inside an anonymous namespace), but they will share a common global variable for `std::locale::_S_once` (declared in `locale_classes.h` as a static class variable). When the shared library reaches `std::locale::_S_Initialize()`, it will consume the global `std::locale::_S_once` to initialize its local buffer `c_locale`. So if the main executable later reaches `std::locale::_S_Initialize()`, it will not go through `std::locale::_S_initialize_once` because `std::locale::_S_once` is already consumed, and so the local buffer `c_locale` of the main executable will remain uninitialized. Hence uses of `std::locale::classic()` from the main executable will return a pointer to an uninitialized locale, and using it will result in a null pointer dereference.

When we reproduce the crash, we observe this behavior, with a first call to `liblgpllibs.so`'s `std::locale::_S_initialize` occuring from `liblgpllibs.so` (and consuming the global `std::locale::_S_once`), and a later call to `firefox`'s `std::locale::_S_initialize` through `std::locale::classic()` (called from graphics code in `libxul.so`) resulting in the crash.

[:sergesanspaille] has suggestions, which we will forward, about how these Firefox packages could be built without `-static-libstc++` and still use a different version of `libstdc++` than the one available on the platform.

Edit: [1] As explained in comment 7, this behavior is only observed when using `-static-libstdc++ -Bsymbolic-functions`, so it's hard to qualify it as a `stdlibc++` bug.