This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCC 3.4 and glibc/nptl: Cancellation broken


On both i686 and amd64 (no other platforms tested) the current CVS
glibc with nptl enabled does not pass the nptl testsuite when compiled
with GCC 3.4 CVS.  The failing tests include:

tst-cancelx{4,5,10,11,12,14,15,16,17,18,20,21}
tst-cleanupx{0,1,3,4}

Note that the tests without the 'x' work.  AFAIK the only difference
between them is the usage of -fexceptions for the ones with the x.

On AMD64 I get the following (i686 is equivalent) backtrace for
nptl/tst-cleanupx0:

(gdb) r --direct
Starting program: /usr/src/packages/BUILD/glibc-2.3/cc-nptl/nptl/tst-cleanupx0 --direct

Program received signal SIGABRT, Aborted.
0x0000002a957aeb03 in raise () from /lib64/tls/libc.so.6
(gdb) bt
#0  0x0000002a957aeb03 in raise () from /lib64/tls/libc.so.6
#1  0x0000002a957b00fe in abort () from /lib64/tls/libc.so.6
#2  0x0000000000401ae5 in _Unwind_SetGR (context=0x3f0f, index=16143, val=16143) at ../../gcc/unwind-dw2.c:240
#3  0x00000000004050f5 in __gcc_personality_v0 (version=16143, actions=16143, exception_class=6, ue_header=0x2a95570120, context=0x7fbfffed30) at ../../gcc/unwind-c.c:190
#4  0x0000002a959c4a65 in _Unwind_ForcedUnwind_Phase2 () from /lib64/libgcc_s.so.1
#5  0x0000002a959c4b7c in _Unwind_ForcedUnwind () from /lib64/libgcc_s.so.1
#6  0x0000002a95677190 in *__GI___pthread_unwind (buf=0x7fbffff020) at unwind.c:130
#7  0x0000002a95675f00 in __pthread_setcanceltype (type=16143, oldtype=0x3f0f) at pthreadP.h:149
#8  0x00000000004012c7 in do_test () at tst-cleanup0.c:62
#9  0x00000000004015b2 in main (argc=2, argv=0x7fbffff0e8) at test-skeleton.c:254
(gdb) shell cat /proc/16143/maps
00400000-00406000 r-xp 00000000 08:07 39589218                           /usr/src/packages/BUILD/glibc-2.3/cc-nptl/nptl/tst-cleanupx0
00506000-00507000 rw-p 00006000 08:07 39589218                           /usr/src/packages/BUILD/glibc-2.3/cc-nptl/nptl/tst-cleanupx0
00507000-00528000 rwxp 00000000 00:00 0 
2a95556000-2a9556b000 r-xp 00000000 08:07 21112540                       /lib64/ld-2.3.3.so
2a9556b000-2a9556c000 rw-p 00000000 00:00 0 
2a9556f000-2a95571000 rw-p 00000000 00:00 0 
2a9566b000-2a9566d000 rw-p 00015000 08:07 21112540                       /lib64/ld-2.3.3.so
2a9566d000-2a9567a000 r-xp 00000000 08:07 21111560                       /lib64/tls/libpthread.so.0
2a9567a000-2a9576d000 ---p 0000d000 08:07 21111560                       /lib64/tls/libpthread.so.0
2a9576d000-2a9577c000 rw-p 00000000 08:07 21111560                       /lib64/tls/libpthread.so.0
2a9577c000-2a95780000 rw-p 00000000 00:00 0 
2a95780000-2a958a1000 r-xp 00000000 08:07 21111556                       /lib64/tls/libc.so.6
2a958a1000-2a95980000 ---p 00121000 08:07 21111556                       /lib64/tls/libc.so.6
2a95980000-2a959ba000 rw-p 00100000 08:07 21111556                       /lib64/tls/libc.so.6
2a959ba000-2a959be000 rw-p 00000000 00:00 0 
2a959be000-2a959c8000 r-xp 00000000 08:07 21111647                       /lib64/libgcc_s.so.1
2a959c8000-2a95abe000 ---p 0000a000 08:07 21111647                       /lib64/libgcc_s.so.1
2a95abe000-2a95ac9000 rw-p 00000000 08:07 21111647                       /lib64/libgcc_s.so.1
7fbfffe000-7fc0000000 rwxp fffffffffffff000 00:00 0 

The problem seems to be that the unwind functions are both in the
executable image and in libgcc_s which is loaded by glibc (via
dlopen).

The actual problem then is that the called _Unwind_ForcedUnwind is
From gcc_s and initializes its static dwarf_reg_size_table.  But later
the _Unwind_SetGR in the executable is called from the personality
routine which looks at its own static dwarf_reg_size_table - and this
one was never initialized and this leads to the abort.  

The unwind functions in the executable come from libgcc_eh.a and those
From libgcc_s are dynamically loaded.

Note this works with GCC 3.3.

How is this supposed to work properly - and why does it work with 3.3
but not with 3.4?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SuSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

Attachment: pgp00000.pgp
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]