no, it's not fakeroot, it's make segfaulting ...
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16911)]
0x4091fd20 in __canonicalize_funcptr_for_compare () from
/lib/libpthread.so.0
(gdb) bt
#0 0x4091fd20 in
I would have thought that old (r11) would have just been copied to
r26. Could you send preprocessed source and compilation details?
This is now filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23369
I have reassigned the fakeroot bug to gcc-4.0 and marked it up accordingly.
randolph
--
(I trimmed the cc list a bit)
Dave,
Could this actually be a gcc problem?
Take a look at this:
(gdb) bt
#0 0x406dbd20 in __canonicalize_funcptr_for_compare ()
from /usr/lib/debug/libpthread.so.0
#1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8,
oact=0xc0241f50)
at
#1 0x406d7424 in __pthread_sigaction (sig=18, act=0xc0241ec8,
oact=0xc0241f50)
at signals.c:106
106 if (old == SIG_IGN || old == SIG_DFL || old == SIG_ERR)
(gdb) print old
Address requested for identifier old which is in register $r11
(gdb) print /x $r11
$6 = 0x0
The handling of function pointers in 4.0 branch was broken prior to
this change:
2005-07-02 Jeff Law [EMAIL PROTECTED]
* tree-ssa-dom.c (find_equivalent_equality_comparison): Do not
a eliminate type conversion which feeds an equality comparison
if the original type
The buildd in question is currently running a 2.4.26-64 kernel.
Cool (I didn't thought that there was still systems running 2.4)
In fact while simply rebuilding a kernel (as root, without fakeroot), I also
observe a segfault with 2.6.8 and 2.6.10 (on c110 and d380) but panicing
2.6.12
On Fri, Aug 12, 2005 at 11:51:30AM +0200, Joel Soete wrote:
The buildd in question is currently running a 2.4.26-64 kernel.
Cool (I didn't thought that there was still systems running 2.4)
Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that
this problem happens to go away
Well, sarge also shipped as 2.6-only, for hppa; so if the answer is that
this problem happens to go away when upgrading to 2.6, that's probably
acceptable, since 2.4 kernels will have been unsupported on hppa for a full
stable release by the time etch comes out.
It doesn't go away with 2.6.
no, it's not fakeroot, it's make segfaulting ...
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16911)]
0x4091fd20 in __canonicalize_funcptr_for_compare () from
/lib/libpthread.so.0
(gdb) bt
#0 0x4091fd20 in
22:53:08 +0800
Subject : Re: Bug#321785: fakeroot: segfaults on [hppa]
Confirmed. We are passing a function pointer with a value of -2 into
__cffc, which should not happen...
Is -2 a special signal number?
I don't think so. in any case, others have observed that if they use an
older glibc
@lists.debian.org,[EMAIL PROTECTED]
Date : Wed, 10 Aug 2005 22:53:08 +0800
Subject : Re: Bug#321785: fakeroot: segfaults on [hppa]
Confirmed. We are passing a function pointer with a value of -2 into
__cffc, which should not happen...
Is -2 a special signal number?
I don't
no, it's not fakeroot, it's make segfaulting ...
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16911)]
0x4091fd20 in __canonicalize_funcptr_for_compare () from /lib/libpthread.so.0
(gdb) bt
#0 0x4091fd20 in __canonicalize_funcptr_for_compare ()
no, it's not fakeroot, it's make segfaulting ...
[...]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 16911)]
0x4091fd20 in __canonicalize_funcptr_for_compare () from
/lib/libpthread.so.0
(gdb) bt
#0 0x4091fd20 in
Confirmed. We are passing a function pointer with a value of -2 into
__cffc, which should not happen...
Is -2 a special signal number?
I don't think so. in any case, others have observed that if they use an
older glibc, this problem does not happen.
randolph
--
To UNSUBSCRIBE, email to
Confirmed. We are passing a function pointer with a value of -2 into
__cffc, which should not happen...
Is -2 a special signal number?
I don't think so. in any case, others have observed that if they use an
older glibc, this problem does not happen.
Not sure this is related, but
--j79F1xXV029481.1123599719/bolero.cs.tu-berlin.de--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
fakeroot-tcp shows the same behaviour. reverting back to glibc-2.3.2
is a workaround.
Does building fakeroot against glibc 2.3.5 change anything?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
17 matches
Mail list logo
