Package: libc6.1-alphaev67
Version: 2.19-19
Severity: important
Justification: breaks other software when installed
User: [email protected]
Usertags: alpha
Something has gone terribly wrong with the libc6.1-alphaev67 package
with the 2.19-19 upload. A segmentation violation occurs every time
a shell command is run. Everything is okay if only libc6.1 installed.
With libc6.1-alphaev67 also installed it appears that commands execute
correctly and the segmentation violation occurs near the end or after
command execution.
Running this in a buildd chroot I install libc6.1-alphaev67 and dpkg
falls over in the postinstall with a segfault. Then running ls a
segfault occurs. It appears that the segfault is actually caused by
iconv rather than ls, so running gdb on the core dump:
(sid)mjc@electro:~/.../glibc/glibc-2.19$ gdb iconv core
[snip]
Core was generated by `iconv -l'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000002000007ac44 in __GI___call_tls_dtors () at
cxa_thread_atexit_impl.c:83
83 cxa_thread_atexit_impl.c: No such file or directory.
(gdb) dir stdlib
Source directories searched: /home/mjc/debian/glibc/glibc-2.19/stdlib:$cdir:$cwd
(gdb) bt full
#0 0x000002000007ac44 in __GI___call_tls_dtors () at
cxa_thread_atexit_impl.c:83
No locals.
#1 0x000002000007a3fc in __run_exit_handlers (status=2006560,
listp=0x200001ea020 <__exit_funcs>,
run_list_atexit=run_list_atexit@entry=true)
at exit.c:40
No locals.
#2 0x000002000007a550 in __GI_exit (status=<optimized out>) at exit.c:104
No locals.
#3 0x0000000120002ea8 in ?? ()
No symbol table info available.
#4 0x000002000005ec30 in __libc_start_main (main=0x1200023a0, argc=<optimized
out>,
argv=0x11ff9bbf8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>,
stack_end=0x11ff9bbe0) at libc-start.c:287
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 4831893040, 4830229088,
4830229097,
4837948556, 4837948548, -6904472293805735848,
-6904474492829226072,
-6904474497599762104, 4650248090236747776, 0, 0, 0, 0, 0, 0,
0},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data =
{prev = 0x0,
cleanup = 0x0, canceltype = 0}}}
not_first_call = <optimized out>
#5 0x0000000120002fb8 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) list
78 /* Call the destructors. This is called either when a thread returns
from the
79 initial function or when the process exits via the exit function. */
80 void
81 __call_tls_dtors (void)
82 {
83 while (tls_dtor_list)
84 {
85 struct dtor_list *cur = tls_dtor_list;
86 tls_dtor_list = tls_dtor_list->next;
87
(gdb) disass /m
Dump of assembler code for function __GI___call_tls_dtors:
82 {
0x000002000007abf0 <+0>: ldah gp,23(t12)
0x000002000007abf4 <+4>: lda gp,27400(gp)
0x000002000007abfc <+12>: lda sp,-48(sp)
0x000002000007ac04 <+20>: stq s0,8(sp)
0x000002000007ac08 <+24>: stq s1,16(sp)
0x000002000007ac0c <+28>: stq s2,24(sp)
0x000002000007ac10 <+32>: stq s3,32(sp)
0x000002000007ac1c <+44>: stq s4,40(sp)
0x000002000007ac20 <+48>: stq ra,0(sp)
83 while (tls_dtor_list)
0x000002000007abf8 <+8>: ldq t12,-32328(gp)
0x000002000007ac00 <+16>: lda a0,-30936(gp)
0x000002000007ac34 <+68>: rduniq
0x000002000007ac38 <+72>: addq a0,v0,v0
0x000002000007ac3c <+76>: ldah v0,0(v0)
0x000002000007ac40 <+80>: unop
=> 0x000002000007ac44 <+84>: ldq s0,72(v0)
0x000002000007ac48 <+88>: bne s0,0x2000007ac94
<__GI___call_tls_dtors+164>
0x000002000007ac4c <+92>: br 0x2000007ad20
<__GI___call_tls_dtors+304>
0x000002000007ac74 <+132>: ldq t12,-32328(gp)
0x000002000007ac78 <+136>: lda a0,-30936(gp)
0x000002000007ac7c <+140>: jsr ra,(t12),0x2000007ac80
<__GI___call_tls_dtors+144>
0x000002000007ac80 <+144>: ldah gp,23(ra)
0x000002000007ac84 <+148>: ldah v0,0(v0)
0x000002000007ac88 <+152>: lda gp,27256(gp)
0x000002000007ac8c <+156>: ldq s0,72(v0)
0x000002000007ac90 <+160>: beq s0,0x2000007ad20
<__GI___call_tls_dtors+304>
[snip]
gdb) print /x $v0
$1 = 0x40000216920
(gdb) print /x $a0
$2 = 0x200001e9e20
The address pointed to by tls_dtor_list which should be in v0 at
the point of the segfault does look wonky.
I not convinced this is actually a glibc fault; the changelog for
the 2.19-19 upload indicates that the only code change form 2.19-18
is hurd specific, however 2.19-18 was working fine, thus suggestive
this might be a compiler/linker cockup.
Also I had compiled glibc 2.19-18 a month or two ago with a compiler
that had been modified to generate code with the BWX (byte-word
extension giving atomic byte and 16-bit word writes) by default and
was surprised to see the number of segfaults appearing in the glibc
test suite! I didn't analyse any further at the time but my guess
is that it is the same segfault I am seeing with libc6.1-alphaev67
now so that suggests there is a change in some other package (gcc?
binutils?) that is buggy or is exposing a pre-existing bug in glibc.
Cheers
Michael.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
