Воспроизводится на i586 (3.2.1-un-def-alt2) и x86_64 (3.2.1-std-def-alt2) с libqt4-core-4.8.0-alt1; помогает откат на libqt4-*-4.7.4-alt3.M60P.1.

Для удобства -- стоя в t6/branch/files/x86_64/RPMS/:
rpm -Uvh --oldpackage libqt4-core-4.7.4-alt3.M60P.1.x86_64.rpm libqt4-xml-4.7.4-alt3.M60P.1.x86_64.rpm libqt4-gui-4.7.4-alt3.M60P.1.x86_64.rpm libqt4-dbus-4.7.4-alt3.M60P.1.x86_64.rpm libqt4-opengl-4.7.4-alt3.M60P.1.x86_64.rpm libqt4-network-4.7.4-alt3.M60P.1.x86_64.rpm qt4-common-4.7.4-alt3.M60P.1.x86_64.rpm

или стоя в t6/branch/files/i586/RPMS/:
rpm -Uvh --oldpackage libqt4-core-4.7.4-alt3.M60P.1.i586.rpm libqt4-xml-4.7.4-alt3.M60P.1.i586.rpm libqt4-gui-4.7.4-alt3.M60P.1.i586.rpm libqt4-dbus-4.7.4-alt3.M60P.1.i586.rpm libqt4-sql-4.7.4-alt3.M60P.1.i586.rpm libqt4-svg-4.7.4-alt3.M60P.1.i586.rpm libqt4-designer-4.7.4-alt3.M60P.1.i586.rpm libqt4-webkit-4.7.4-alt3.M60P.1.i586.rpm libqt4-opengl-4.7.4-alt3.M60P.1.i586.rpm libqt4-script-4.7.4-alt3.M60P.1.i586.rpm libqt4-network-4.7.4-alt3.M60P.1.i586.rpm qt4-common-4.7.4-alt3.M60P.1.i586.rpm rpm-macros-qt4-4.7.4-alt3.M60P.1.i586.rpm

Также наблюдается некритичный, но некрасивый регресс в psi-plus/psi по части пиктограммок.

У меня на Сизифе не воспроизводится i586, 3.2.1-std-def-alt1, libqt4-core-4.8.0-alt1

(В ответ на комментарий №2)
> У меня на Сизифе не воспроизводится i586, 3.2.1-std-def-alt1,
> libqt4-core-4.8.0-alt1
На 3.2.1-std-def-alt2 тоже не воспроизводиться.

P.S.
Отчеты лучше делать с установленным -debuginfo

(В ответ на комментарий №1)
> Также наблюдается некритичный, но некрасивый регресс в psi-plus/psi по части
> пиктограммок.
У меня все ок. От видео зависит, видимо. Попробуйте
export QT_GRAPHICSSYSTEM=x11

На p6 3.0.17-std-def-alt0.M60P.2 c qt-4.8 тоже не воспроизводиться.
Прилагайте более подробную инфу (установив virtualbox-debuginfo)

Created attachment 5299 [details]
Лог gdb на x86_64

gdb пришлось запускать от рута

# uname -a
Linux alexhome 3.2.1-std-def-alt1 #1 SMP Thu Jan 19 07:50:09 UTC 2012 x86_64 GNU/Linux

Ядро потом обновлю, но судя по вышенаписанному это не поможет.

(В ответ на комментарий №4)
> (В ответ на комментарий №1)
> > Также наблюдается некритичный, но некрасивый регресс в psi-plus/psi по части
> > пиктограммок.
> У меня все ок. От видео зависит, видимо. Попробуйте
> export QT_GRAPHICSSYSTEM=x11

Смайлики (особенно анимированные) в psi+ корёжит у меня на i586 с интеловским видео (945GME) и на x86_64 с nouveau (8800GT)

export QT_GRAPHICSSYSTEM=x11 вроде не помогает, если можно её задавать в терминале перед запуском оттуда psi+

*** Bug 26852 has been marked as a duplicate of this bug. ***

Попробуйте пересобрать virtualbox с новым qt (я бы и сам, но не воспроизводиться)

Пересобирал, результат тот-же. Ну и в psi+ кирдык смайликам - подтверждаю.

Актуально...

Актуально, к сожалению.

Created attachment 5300 [details]
vb-strace.log

Вывод strace мне ни о чём не говорит.

Тоже попробовал пересобрать VB, но ничего не изменилось.

Что-то с тредами. Пока нигде ничего подобного не нашел.

Еще было бы неплохо обновить virtualbox

Я попробовал собрать VB 4.1.8, а также испытал собранный неделю назад 3.2.14. Оба падают точно так же, как и сизифный.
Вызов __tls_get_addr@plt почему-то возвращает 0, и при попытке обратиться по этому адресу происходит сегфолт.
На всякий случай попробовал Qt с отключённой оптимизацией, код изменился, но в целом проблема точно та же.
Это всё на x86_64, как это выглядит на i586 посмотреть негде.
Наверное попробую ещё собрать Qt отключив в этом файле TLS, может что прояснится... А пока мне ничего не понятно.

(В ответ на комментарий №16)
> Наверное попробую ещё собрать Qt отключив в этом файле TLS, может что
> прояснится... А пока мне ничего не понятно.

В общем сборка Qt с #undef HAVE_TLS в файле thread/qthread_unix.cpp в строке 115 вроде позволяет обойти проблему, по-крайней мере у меня теперь снова запускается VirtualBox. Но по-прежнему не понятно, кто виноват и что делать в случае использования TLS?

А как Qt с #undef HAVE_TLS в файле thread/qthread_unix.cpp ведет себя PSI+? Смайлики отображаются?

(В ответ на комментарий №18)
> А как Qt с #undef HAVE_TLS в файле thread/qthread_unix.cpp ведет себя PSI+?
> Смайлики отображаются?

Нет, это не починилось, к сожалению. Это либо ошибка в другом месте, либо разные побочные действия одного разлома.

Откат на предыдущий QT фиксит как VirtualBox, так и PSI+

Видимо, из-за того, что, когда в
QThreadData::deref()
происходит
delete this
, currentThreadData не приравнивают к 0  и он остается указателем на удаленный объект, когда его пытаются возвратить в
get_thread_data()
, а без HAVE_TLS нет и currentThreadData и этого рассинхрона не происходит.
Как исправлять мыслей пока нет.

Для psi+ нашлось исправление.
https://bugzilla.altlinux.org/show_bug.cgi?id=26874

(В ответ на комментарий №21)
> Как исправлять мыслей пока нет.

Вряд ли здесь вина libqt4-core. Я, кажется, нашёл минимальный сценарий, когда происходит эта ошибка.
Программа загружает libtest1.so с помощью dlopen. Библиотека libtest1 слинкована с libGL.so и libtest2.so. В libtest2 используется TLS.
При вызове из программы функции из libtest2 которая использует TLS наблюдается ошибка в точности такая, как в случае с VirtualBox (который использует такой же сценарий).
Если libGL из libtest1 выкинуть, то проблемы нет. У меня под подозрением glibc и gcc. Ну и libGL, наверное.
Далее прикрепляю тестовый проект на cmake.

Created attachment 5312 [details]
минимальный проект с ошибкой

Лог из GDB

(gdb) run
Starting program: /tmp/testtls/testtls 
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff68336a0 in lib2_get () at /tmp/testtls/module2.cpp:11
11              return data;
(gdb) bt
#0  0x00007ffff68336a0 in lib2_get () at /tmp/testtls/module2.cpp:11
#1  0x00007ffff6cb4685 in lib1_run () at /tmp/testtls/module1.cpp:16
#2  0x0000000000400c37 in main () at /tmp/testtls/testtls.cpp:26
(gdb) disassemble 
Dump of assembler code for function lib2_get():
   0x00007ffff683368c <+0>:     push   %rbp
   0x00007ffff683368d <+1>:     mov    %rsp,%rbp
   0x00007ffff6833690 <+4>:     data32 lea 0x200928(%rip),%rdi        # 0x7ffff6a33fc0
   0x00007ffff6833698 <+12>:    data32 data32 callq 0x7ffff68335a8 <__tls_get_addr@plt>
=> 0x00007ffff68336a0 <+20>:    mov    (%rax),%eax
   0x00007ffff68336a2 <+22>:    leaveq 
   0x00007ffff68336a3 <+23>:    retq   
End of assembler dump.
(gdb) info registers rax
rax            0x0      0
(gdb)

В общем нужны специалисты. Наверное надо на кого-то ещё ошибку повесить.

(В ответ на комментарий №23)
> Ну и libGL, наверное.
Судя по тому, что у меня libGL от nvidia и не падает vbox и testtls, похоже, libGL

Возможно, но в примере функции из libGL вообще не вызываются, glEnable там только чтобы библиотека слинковалась.

Собственно, почему я именно libGL линковал — из всех других только у неё при загрузке установлено в единицу поле l_need_tls_init в функции dl_open_worker из файла dl-open.c
Если кто знает, что для этого надо, то можно посмотреть со своей библиотекой вместо libGL. Я о TLS узнал только из-за этой баги.

В общем-то похоже на
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637239
https://bugs.gentoo.org/353224

В общем помогает патч на glibc из этого коммита
http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d26dfc60edc8#patch4

Тады на glibc

ok, надо будет сбэкпортить.

Алексей, спасибо!

glibc-6:2.11.3-alt7 -> sisyphus:

* Mon Feb 06 2012 Dmitry V. Levin <ldv@altlinux> 6:2.11.3-alt7
- Backported upstream fixes for Sourceware#12453 (closes: #26848),
  Sourceware#12350 and Sourceware#12811.

ack, вот эти работают:
glibc-core-2.11.3-alt7
libqt4-core-4.8.0-alt1
virtualbox-4.1.6-alt1