Bug#321785: fakeroot: segfaults on [hppa]

2005-08-15 Thread John David Anglin
  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 ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)
 
 Confirmed. We are passing a function pointer with a value of -2 into
 __cffc, which should not happen...

I've posted a candidate gcc fix here:
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00923.html

As I mentioned earlier today to Randolph, I think there should possibly
be a pa specific implementation of sigaction that avoids doing function
pointer canonicalization.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread Joel Soete


 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 the same c110 and d380) as well as 2.6.13-rc6 on d380 and b2k.

  Fwiw with kernel 2.6.11.12, the rebuild runs fine on this same d380 and b2k.

 Well, there have certainly been various and sundry known kernel issues on
 hppa, but this seems wholly unrelated to them.

  That's confusing me: is there actualy a pb in libc or do we need some
  constraint to install this new libc?

 glibc seems to be the one thing that's changed; running make manually with
 a copy of glibc 2.3.2 in the chroot works just fine.

Thanks,
Joel

---
A free anti-spam and anti-virus filter on all Scarlet mailboxes
More info on http://www.scarlet.be/




Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread Steve Langasek
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 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.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread Randolph Chung
 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.

randolph



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread Randolph Chung

(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 signals.c:106
#2  0x4035f950 in *__GI___sigaction (sig=value optimized out,
act=value optimized out, oact=value optimized out)
at ../linuxthreads/sysdeps/pthread/sigaction.c:42
#3  0x4035f748 in __bsd_signal (sig=18,
[EMAIL PROTECTED]: 0x42410 __gmon_start__+92828) at signal.c:47
#4  0x0001d690 in main ()
(gdb) frame 1
#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
(gdb) print /x $pc
$7 = 0x406d7424
(gdb) disassemble $pc-16 $pc+4
Dump of assembler code from 0x406d7414 to 0x406d7428:
0x406d7414 __pthread_sigaction+252:   stw r20,-138(,sp)
0x406d7418 __pthread_sigaction+256:   copy r19,r4
0x406d741c __pthread_sigaction+260:   b,l 0x406dbcd8 
__canonicalize_funcptr_for_compare,rp

0x406d7420 __pthread_sigaction+264:   ldo -2(r11),r26
0x406d7424 __pthread_sigaction+268:   copy r4,r19
End of assembler dump.
(gdb)

Why is it doing that ldo -2(r11),r26 ?

I think this version of glibc is built with gcc-4.0

randolph


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread John David Anglin
 #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
 (gdb) print /x $pc
 $7 = 0x406d7424
 (gdb) disassemble $pc-16 $pc+4
 Dump of assembler code from 0x406d7414 to 0x406d7428:
 0x406d7414 __pthread_sigaction+252:   stw r20,-138(,sp)
 0x406d7418 __pthread_sigaction+256:   copy r19,r4
 0x406d741c __pthread_sigaction+260:   b,l 0x406dbcd8 
 __canonicalize_funcptr_for_compare,rp
 0x406d7420 __pthread_sigaction+264:   ldo -2(r11),r26
 0x406d7424 __pthread_sigaction+268:   copy r4,r19
 End of assembler dump.
 (gdb)
 
 Why is it doing that ldo -2(r11),r26 ?

I would have thought that old (r11) would have just been copied to
r26.  Could you send preprocessed source and compilation details?

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 or either operand in the comparison is a
function pointer.

This change is in 4.0.1.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread tsd78163

 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 or either operand in the comparison is a
   function pointer.

 This change is in 4.0.1.

Latest gcc-4.0
debian/changelog said:
gcc-4.0 (4.0.1-4) unstable; urgency=low

  * Enable the biarch compiler for powerpc (closes: #268023).
  * Update to CVS 20050806, taken from the gcc-4_0-branch.
...

but I don't know how to determine which compiler was used to build glibc.

Was it still possible to rebuild libc6 with gcc-3.3.5?

Thanks,
Joel

---
A free anti-spam and anti-virus filter on all Scarlet mailboxes
More info on http://www.scarlet.be/




Bug#321785: fakeroot: segfaults on [hppa]

2005-08-12 Thread Randolph Chung
 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
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-11 Thread Joel Soete
-- Initial header ---

From  : Randolph Chung [EMAIL PROTECTED]
To  : John David Anglin [EMAIL PROTECTED]
CC  :
[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL 
PROTECTED],debian-hppa@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 think so. in any case, others have observed that if they use an
 older glibc, this problem does not happen.

 randolph

Hello all,

Which kernel was it?

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 the same c110 and d380) as well as 2.6.13-rc6 on d380 and b2k.

Fwiw with kernel 2.6.11.12, the rebuild runs fine on this same d380 and b2k.

That's confusing me: is there actualy a pb in libc or do we need some
constraint to install this new libc?

Thanks,
Joel

---
NOTE! My email address is changing to ... @scarlet.be
Please make the necessary changes in your address book. 






Bug#321785: fakeroot: segfaults on [hppa]

2005-08-11 Thread Steve Langasek
On Thu, Aug 11, 2005 at 12:49:24PM +0200, Joel Soete wrote:
 -- Initial header ---

 From  : Randolph Chung [EMAIL PROTECTED]
 To  : John David Anglin [EMAIL PROTECTED]
 CC  :
 [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL 
 PROTECTED],debian-hppa@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 think so. in any case, others have observed that if they use an
  older glibc, this problem does not happen.

  randolph

 Hello all,

 Which kernel was it?

The buildd in question is currently running a 2.4.26-64 kernel.

 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 the same c110 and d380) as well as 2.6.13-rc6 on d380 and b2k.

 Fwiw with kernel 2.6.11.12, the rebuild runs fine on this same d380 and b2k.

Well, there have certainly been various and sundry known kernel issues on
hppa, but this seems wholly unrelated to them.

 That's confusing me: is there actualy a pb in libc or do we need some
 constraint to install this new libc?

glibc seems to be the one thing that's changed; running make manually with
a copy of glibc 2.3.2 in the chroot works just fine.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer  to set it on, and I will move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Bug#321785: fakeroot: segfaults on [hppa]

2005-08-11 Thread John David Anglin
  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 ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)

GSIGNAL(3) Linux Programmer's ManualGSIGNAL(3)

NAME
   gsignal, ssignal - software signal facility

SYNOPSIS
   #include signal.h

   typedef void (*sighandler_t)(int);

   int gsignal(signum);

   sighandler_t ssignal(int signum, sighandler_t action);

DESCRIPTION
   Don't  use  these  functions under Linux.  Due to a historical mistake,
   under Linux these functions  are  aliases  for  raise()  and  signal(),
   respectively.

   ...

CONFORMING TO
   SVID2, XPG2.  These functions are available  under  AIX,  DG-UX,  HPUX,
   SCO, Solaris, Tru64.  They are called obsolete under most of these sys-
   tems, and are broken under Linux libc and  glibc.   Some  systems  also
   have gsignal_r() and ssignal_r().

I'm guessing that ssignal is called with action -2.  I have no idea
what that's supposed to do.  __cffc accepts small positive function
pointer addresses and -1 as special.  It doesn't attempt to canonicalize
them.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-10 Thread John David Anglin
  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 ()
 from /lib/libpthread.so.0
  #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
  #2  0x405cc950 in sigaction () from /lib/libc.so.6
  #3  0x405cc748 in ssignal () from /lib/libc.so.6
  #4  0x0001d690 in main ()
  (gdb)
 
 Confirmed. We are passing a function pointer with a value of -2 into
 __cffc, which should not happen...

Is -2 a special signal number?

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-10 Thread Randolph Chung

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 [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-10 Thread John David Anglin
 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 your put_user kernel patch fixed
some c++ issues.  There are also issues with the alignment of
alternate signal stacks.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-10 Thread Randolph Chung
 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 ()
from /lib/libpthread.so.0
 #1  0x4091b424 in sigaction () from /lib/libpthread.so.0
 #2  0x405cc950 in sigaction () from /lib/libc.so.6
 #3  0x405cc748 in ssignal () from /lib/libc.so.6
 #4  0x0001d690 in main ()
 (gdb)

Confirmed. We are passing a function pointer with a value of -2 into
__cffc, which should not happen...

This code is a bit fragile wrt to glibc's and the toolchain's idea of
the GOT layout and function pointer initialization. Carlos and Dave
might have a better idea of what is happening :)

I've copied Dave and Carlos in case they don't read these lists. Dave
and Carlos, this is a problem with the new glibc in Debian unstable.
looks like any app that links libpthread will segfault.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-08 Thread Matthias Klose
fakeroot-tcp shows the same behaviour. reverting back to glibc-2.3.2
is a workaround.

  Matthias


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-07 Thread Paul Brossier
Package: fakeroot
Version: 1.4.2
Severity: grave
Justification: renders package unusable

the hppa builds are failing with the following message:

dpkg-source: extracting fftw3 in fftw3-3.0.1
dpkg-buildpackage: source package is fftw3
dpkg-buildpackage: source version is 3.0.1-12
dpkg-buildpackage: host architecture hppa
 /usr/bin/fakeroot debian/rules clean
/usr/bin/fakeroot: line 152:  3420 Segmentation fault  
FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB $@
**
Build finished at 20050807-0614
FAILED [dpkg-buildpackage died]
Purging chroot-unstable/build/buildd/fftw3-3.0.1

cheers, piem


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages fakeroot depends on:
ii  libc6 2.3.5-3GNU C Library: Shared libraries an

fakeroot recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#321785: fakeroot: segfaults on [hppa]

2005-08-07 Thread Clint Adams
 dpkg-source: extracting fftw3 in fftw3-3.0.1
 dpkg-buildpackage: source package is fftw3
 dpkg-buildpackage: source version is 3.0.1-12
 dpkg-buildpackage: host architecture hppa
  /usr/bin/fakeroot debian/rules clean
 /usr/bin/fakeroot: line 152:  3420 Segmentation fault  
 FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB $@
 **
 Build finished at 20050807-0614
 FAILED [dpkg-buildpackage died]
 Purging chroot-unstable/build/buildd/fftw3-3.0.1

Does fakeroot-tcp work?  Is there a SysV IPC problem on the box?


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]