Мультитредное

[spamsink]

Несколько дней коллега бился над проблемой, почему вдруг программа при завершении вдруг стала падать с ошибкой в malloc/free. Оказывается, кто-то в другом штате на другом берегу стал линковать одну из используемых динамических библиотек с -lpthread, а программа, которая этой библиотекой пользовалась, об этом деле ни сном ни духом.
Результат: адрес объекта std::locale, про который библиотека думала, что он thread-local и требует освобождения, динамический загрузчик честно-благородно брал из сегмента данных основной программы.
Перелинковали основную программу с -lpthread — всё починилось.

Comments

[fatoff.livejournal.com]

Забыл, потому что не знал. GCC опции как поставлены в своём единственно текущем проекте под Linux, так не трогал и не интересовался.

Если верить этому популярному объяснению то опция -pthread одновременно влияющая на компиляцию и линковку, очень коварная, по меньшей мере.

[dvv.livejournal.com]

Давно уже этот опшын пора сделать дифолтным и вообще не опшыном.

А в принципе — в Стандарте сказано, что тот объект thread local? Или вообще thread safe? Если нет, то это бардак, что библиотека себе такое позволяет.

[spamsink]

Как минимум thread safe. Безотносительно к языку, если библиотека хочет сделать себе thread-local объект с именем, идентичным имени глобального объекта, то как должен вести себя динамический загрузчик, если тред всего один?

[dvv.livejournal.com]

TSD/thread-local — это вообще отдельное от динамической загрузки именное пространство. Чё-то у вас там кластерный поёб какой-то.

[spamsink]

Именно поэтому, если основной процесс этого отдельного именного пространства не завел, думая, что он всегда будет однотредным, динамическая библиотека посасывает.

Это в линуксе clusterfuck, что при подгрузке .so, слинкованной с -lpthread, в процесс, слинкованный без -lpthread, всё тут же не вылетает с ошибкой.

[dvv.livejournal.com]

OK. Thread-local — это объект, "принадлежащий" треду, но ассоциированный с глобальным (в смысле, уникальным на весь процесс) ключом. Ключ этот может быть ассоциирован с глобальным — уникальным на весь процесс! — объектом, имеющим имя в терминах динамического загрузчика. Если уникальность этого глобального объекта каким-то образом нарушается, это есть абсолютная хуйня полная. Хоть динамической загрузкой, хоть чем. К мультитредности это отношения не имеет, вообще говоря.

[spamsink]

Если уникальность этого глобального объекта каким-то образом нарушается

Описанный случай - противоположный.

[yatur.livejournal.com]

Это не мультитредное, это сишное (и сиплюсплюсное). Язык С в 1969-м году задумывался как улучшенный ассемблер, и что-то на одном берегу кто-то будет динамически вызывать код, скомпилированный на другом берегу, им и в голову не приходило. Почти полстолетия позже мы пожинаем плоды :(

[dvv.livejournal.com]

Не надо грязи. Чужой сишный код использовался хоть динамически, хоть как с самого начала существования C.

[yatur.livejournal.com]

Никакой грязи. Разумеется, никакой динамической загрузки библиотек в 1969 году не существовало. Керниган и Риччи не обязаны были быть пророками.

Как раз наоборот, если бы потоки и динамически загружаемые библиотеки существовали "с самого начала существования С", то дизайн языка можно было бы назвать, мягко говоря, не очень продуманным.

[dvv.livejournal.com]

Понятно. Извините за внимание.