Bug 9599 - libpthread Segfault [x86_64]
: libpthread Segfault [x86_64]
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/glibc-core)
: unstable
: all Linux
: P2 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2006-05-22 12:52 by
Modified: 2006-09-15 01:48 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2006-05-22 12:52:26
после каких-то обновлений системных библиотек gimp2-2.2.10-alt1.1
стал вываливаться с segfault.

на i586 воспроизвести не удалось.

strace показывает что падает где-то в районе pthread, но что именно -
непонятно.
------- Comment #1 From 2006-05-22 18:22:12 -------
пересборка избавится от segfault не помогла.
------- Comment #2 From 2006-05-23 00:35:09 -------
Попробую новую версию собрать на неделе.
------- Comment #3 From 2006-05-23 10:44:04 -------
я подозреваю что новая версия GIMP проблемы не решит.

Судя по всему здесь где-то грабли в библиотеках, с которыми gimp слинкован. во
всяком случае:
1) GIMP не пересобирался
2) пересборка не помогает
3) обновлялось что-то из того, с чем он слинкован

2ldv: очень похоже на проблему с gnupg
------- Comment #4 From 2006-05-23 15:26:11 -------
ltrace показывает вот это:
9330 g_free(0xc61d90, 3, 0x422f38, 0, 0x2b7a0db72540)                          
      = 0
9330 g_free(0, 3, 0x422f38, 0, 0x732e6964696d5f72)                             
      = 1
9330 g_free(0xc62820, 3, 0x422f38, 0, 0x2064656e69666564)                      
      = 0
9330 g_free(0xc62930, 3, 0x422f38, 0, 0x2b7a0db72540)                          
      = 0
9330 g_free(0, 3, 0x422f38, 0, 0x2b7a0db72540)                                 
      = 1
9330 g_free(0, 3, 0x422f38, 0, 64)                                             
      = 1
9330 g_direct_hash(1039, 1039, 0x2b7a0d679832, 557, 192)                       
      = 1039
9330 g_direct_equal(550, 1039, 61, 557, 192)                                   
      = 0
9330 g_direct_equal(713, 1039, 61, 557, 192)                                   
      = 0
9330 g_direct_equal(876, 1039, 61, 557, 192)                                   
      = 0
9330 g_free(0, 3, 0x422f38, 0, 128)                                            
      = 1
9330 --- SIGSEGV (Segmentation fault) ---
9330 +++ killed by SIGSEGV +++
------- Comment #5 From 2006-05-23 15:31:15 -------
по наитию было выяснено, что падают любые gnome приложения.

gbd от gnumeric показало:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 9514)]
0x00002aee571276d1 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00002aee571276d1 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
#1  0x00002aee54d0fed3 in __ctype_b_loc () from /lib64/libc.so.6
#2  0x00002aee54d10282 in bindtextdomain () from /lib64/libc.so.6
#3  0x00002aee59ddc9c7 in gpg_err_init () from /usr/lib64/libgpg-error.so.0
#4  0x00002aee59ddcd86 in gpg_err_code_from_errno () from
/usr/lib64/libgpg-error.so.0
#5  0x00007fffffc52ce8 in ?? ()
#6  0x00002aee59cca660 in ?? ()
#7  0x00002aee547b49a8 in _r_debug ()
#8  0x00002aee59ddc86b in _init () from /usr/lib64/libgpg-error.so.0
#9  0x00002aee54ce6000 in ?? ()
#10 0x00002aee546a825b in call_init () from /lib64/ld-linux-x86-64.so.2
#11 0x00002aee546a837e in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#12 0x00002aee5469eb7b in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
------- Comment #6 From 2006-05-23 16:06:40 -------
$ ltrace -f gnumeric
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

------- Comment #7 From 2006-05-23 16:15:01 -------
экпериментальным путём было выявлено, что падают _все_ gnome2 приложения ;(
------- Comment #8 From 2006-05-23 16:15:38 -------
кстати, все они падают сразу после того, как загрузят библиотеки
------- Comment #9 From 2006-05-23 16:18:43 -------
А какое из них самое простое?
------- Comment #10 From 2006-05-23 16:30:29 -------
если из gimp2 вынести всё, что слиновано с libpthread, то работает нормально.

а именно:
libcontroller_midi.so из libgimp

т.е. - все приложения, слинкованные с libpthread и gtk на x86_64 ведут себя
плохо.
------- Comment #11 From 2006-05-23 17:37:36 -------
$ cat test.c
int main(void)
{
        return(0);
}

$gcc -Wl,--no-as-needed -o testa test.c -lgcrypt -lpthread
(gdb) run
Starting program: /home/rider/testa 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 30704)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 30704)]
0x00002ab5495056d1 in pthread_rwlock_wrlock () from /lib64/libpthread.so.0
------- Comment #12 From 2006-05-23 23:14:46 -------
Это даже не libgcrypt, а libgpg-error.so.0:

$ cat foo.c
int main(void) {return 0;}
$ gcc -g -Wall -W -Werror -Wl,--no-as-needed -o foo foo.c -lpthread -lgpg-error
$ ./foo
Segmentation fault

$ LD_LIBRARY_PATH=/usr/lib64/debug gdb -q ./foo
Using host libthread_db library "/usr/lib64/debug/libthread_db.so.1".
(gdb) r
Starting program: /usr/src/RPM/BUILD/glibc-2.3.6/linuxthreads/foo 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 8673)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8673)]
__pthread_rwlock_wrlock (rwlock=0x2aaaab07c140) at descr.h:248
248       return THREAD_SELF;
(gdb) bt
#0  __pthread_rwlock_wrlock (rwlock=0x2aaaab07c140) at descr.h:248
#1  0x00002aaaaae85ed3 in set_binding_values (domainname=0x2aaaaad5add2
"libgpg-error", 
    dirnamep=0x7fffffffe840, codesetp=0x0) at bindtextdom.c:120
#2  0x00002aaaaae86282 in __bindtextdomain (domainname=Variable "domainname" is
not available.
) at bindtextdom.c:356
#3  0x00002aaaaad5a9c7 in gpg_err_init () from /usr/lib64/libgpg-error.so.0
#4  0x00002aaaaad5ad86 in gpg_err_code_from_errno () from
/usr/lib64/libgpg-error.so.0
#5  0x00007fffffffe938 in ?? ()
#6  0x00002aaaaaac1b80 in ?? ()
#7  0x00002aaaaabc19a8 in _r_debug ()
#8  0x00002aaaaad5a86b in _init () from /usr/lib64/libgpg-error.so.0
#9  0x00002aaaaad59040 in ?? ()
#10 0x00002aaaaaab525b in call_init () from /lib64/ld-linux-x86-64.so.2
#11 0x00002aaaaaab537e in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#12 0x00002aaaaaaabb7b in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#13 0x0000000000000001 in ?? ()

Так что это либо linuxthreads, либо libgpg-error.
------- Comment #13 From 2006-05-24 00:53:56 -------
Нет, это не libpgg-error:

$ cat bar.c 
#define _GNU_SOURCE
#include <bits/libc-lock.h>
static void __attribute__((constructor)) myinit(void)
{
        pthread_rwlock_t lock;
        __libc_rwlock_wrlock(lock);
}
$ gcc -g -Wall -W -Werror -fpic -shared -o libbar.so bar.c
$ cat foo.c 
int main(void) {return 0;}
$ gcc -g -Wall -W -Werror -Wl,--no-as-needed -o foo foo.c -lpthread -L. -lbar
$ LD_LIBRARY_PATH=. ./foo
Segmentation fault
------- Comment #14 From 2006-05-24 01:02:22 -------
$ LD_LIBRARY_PATH=.:/usr/lib64/debug gdb -q ./foo
Using host libthread_db library "/usr/lib64/debug/libthread_db.so.1".
(gdb) b __pthread_rwlock_wrlock
Function "__pthread_rwlock_wrlock" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (__pthread_rwlock_wrlock) pending.
(gdb) r
Starting program: /usr/src/RPM/BUILD/glibc-2.3.6/linuxthreads/foo 
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 23293)]
Breakpoint 2 at 0x2aaaaabcd6d0: file rwlock.c, line 414.
Pending breakpoint "__pthread_rwlock_wrlock" resolved
[Switching to Thread 16384 (LWP 23293)]
Breakpoint 2, __pthread_rwlock_wrlock (rwlock=0x7fffffffe810) at rwlock.c:414
414     {
(gdb) display/i $pc
1: x/i $pc  0x2aaaaabcd6d0 <__pthread_rwlock_wrlock>:   push   %rbp
(gdb) stepi
248       return THREAD_SELF;
1: x/i $pc  0x2aaaaabcd6d1 <__pthread_rwlock_wrlock+1>: mov    %fs:0x10,%rbp
(gdb) stepi
Program received signal SIGSEGV, Segmentation fault.
__pthread_rwlock_wrlock (rwlock=0x7fffffffe810) at descr.h:248
248       return THREAD_SELF;
1: x/i $pc  0x2aaaaabcd6d1 <__pthread_rwlock_wrlock+1>: mov    %fs:0x10,%rbp
(gdb) p $fs
$1 = 0
(gdb) p $rbp
$2 = (void *) 0x7fffffffe850
(gdb) p &lock
$4 = (__libc_lock_t *) 0x2aaaab07d580
------- Comment #15 From 2006-05-24 01:08:23 -------
Для сравнения те же тесты на glibc, собранном прежним компилятором:
(gdb) stepi
248       return THREAD_SELF;
1: x/i $pc  0x2aaaaabcd6a1 <__pthread_rwlock_wrlock+1>: mov    %fs:0x10,%rbp
(gdb) p $fs
$1 = 99
(gdb) p $rbp
$2 = (void *) 0x7fffffffe870
(gdb) p &lock
$3 = (__libc_lock_t *) 0x2aaaab07cca0
------- Comment #16 From 2006-05-24 01:37:43 -------
А если линковать не "-lpthread -L. -lbar" а "-L. -lbar -lpthread",
то c пересобранным glibc "LD_LIBRARY_PATH=. ./foo" не падает а виснет.
------- Comment #17 From 2006-05-24 01:47:11 -------
Всё интереснее: foo и libbar, собранные на свежем Сизифе, точно так же падают
на
прежнем.
Просто тест не удаётся повторить на прежнем Сизифе:

old$ gcc -Wl,--no-as-needed -o foo foo.c -lpthread
old$ readelf -d foo |grep -w NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

new$ gcc -Wl,--no-as-needed -o foo foo.c -lpthread
new$ readelf -d foo |grep -w NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
------- Comment #18 From 2006-05-24 01:52:17 -------
Zerg, где ты нашёл такую странную библиотеку?
------- Comment #19 From 2006-05-24 02:07:40 -------
Тест неправильный был, такой имеет смысл:
$ cat bar.c 
#define _GNU_SOURCE
#include <bits/libc-lock.h>
static void __attribute__((constructor)) myinit(void)
{
        static pthread_rwlock_t lock;
        __libc_rwlock_wrlock(lock);
}

$ gcc -g -Wall -W -Werror -Wl,--no-as-needed -o foo foo.c -L. -lpthread -lbar
$ LD_LIBRARY_PATH=. ./foo
Segmentation fault
$ gcc -g -Wall -W -Werror -Wl,--no-as-needed -o foo foo.c -L. -lbar -lpthread
$ LD_LIBRARY_PATH=. ./foo
$ 
Что вполне логично.
------- Comment #20 From 2006-05-24 02:18:36 -------
Кто бы мне объяснил, почему $fs так разительно отличаются на одинаковых foo и
libbar.so - разница только в glibc...
------- Comment #21 From 2006-05-24 09:40:28 -------
Давай пойдём другим путём ;)

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

Вопрос - почему у них не падают ?
------- Comment #22 From 2006-05-24 09:41:12 -------
хотя.. у них же glibc сильно другая ?
------- Comment #23 From 2006-05-24 14:52:16 -------
(In reply to comment #18)
> Zerg, где ты нашёл такую странную библиотеку?
ftp://ftp.gnupg.org/gcrypt/libgpg-error
------- Comment #24 From 2006-05-25 21:10:31 -------
Чего в итоге то делать с этим ?
------- Comment #25 From 2006-05-26 01:49:58 -------
Надо фиксить asm для x86-64.  В nptl есть изменения, похожие на те, что нужны и
здесь.
------- Comment #26 From 2006-05-26 03:18:49 -------
Корректировка asm'а не помогла.  Больше идей нет.
Подготовка новой glibc займёт не меньше недели.
------- Comment #27 From 2006-05-26 03:54:14 -------
$fs не проинициализирован потому что __pthread_initialize_minimal() не была
вызвана.  Кто-то её соптимизировал, наверное.
------- Comment #28 From 2006-05-26 12:32:08 -------
я думаю что надо забить и просто переходить на новую версию libc
------- Comment #29 From 2006-05-26 19:02:44 -------
Fixed in 2.3.6-alt7.