Bug#292673: additional info
While there hasn't been any discussion for glibc bugzilla report #685 [1], private communication with one of the glibc maintainers indicates that this issue is not considered to be a glibc bug because, officially, glibc supports only one thread library at a time: LinuxThreads _or_ NPTL, but not both at the same time. Of course, every distro I know of ships both NPTL and LinuxThreads and the apparently accepted workaround appears to be to use the ld.so that was built for NPTL rather than the one that was built for LinuxThreads (more precisely, the ld.so should be used which uses larger thread descriptors). Thus, I strongly suspect Debian should do the same. Since this bug results in memory corruption that can be very hard to track down, I hope this can be fixed quickly. As a temporary workaround, just doing: # mv /lib/tls/ld-2.3.2.so /lib/ should cure the problem. Thanks, --david [1] http://sources.redhat.com/bugzilla/show_bug.cgi?id=685 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292673: additional info
> On Mon, 28 Feb 2005 09:32:20 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: GOTO> David, does this problem only occurs on ia64? Or i686? To be honest, GOTO> I have concerned this kind of problem - the incompatibility between GOTO> nptl and linuxthreads. As indicated in my bugzilla report, it affects all platforms which defined TLS_DTV_AT_TP. Apart from ia64, that include Alpha, PowerPC, and SH. x86 is not affected since it's thread pointer points to the thread descriptor itself. >> # mv /lib/tls/ld-2.3.2.so /lib/ >> should cure the problem. GOTO> I'm hard to decide to introduce this kind of workaround into the GOTO> package. We have two choices - (1) increasing the size of GOTO> linuxthreads' thread descriptors (2) we don't load nptl library using GOTO> /lib/ld.so. Taking choice (1) is nice idea - because (2) needs GOTO> another consideration about the kernel version capability. Some GOTO> distributions (ex: SuSE/FC) provides the fixed kernel version - OTOH, GOTO> debian has two kernel version series - 2.4 (linuxthreads) and 2.6 GOTO> (nptl). If we can fix this problem with (1), we don't need to be care GOTO> about (2) modifications. If you go with (1), I'd include a sanity check in the build-procedure to ensure that you notice if the thread-descriptor-size diverges between LinuxThreads and NPTL unexpectedly. I don't have a preference on how this problem gets fixed (as long as it does get fixed before Sarge is out...). --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297769: glibc: sched_setaffinity() provides obsolete interface
Package: glibc
Severity: grave
Justification: renders package unusable
The current Sarge glibc still provides the obsolete 2-argument
interface for sched_setaffinity(). As more software is starting to
use this system call, this is becoming a real issue because developers
will have to create a special version just for Debian.
Specifically, in libc6{,.1} currently declares:
extern int sched_setaffinity (__pid_t __pid, __const cpu_set_t *__mask)
__THROW;
whereas the proper interface has 3 arguments:
extern int sched_setaffinity (__pid_t __pid, size_t __cpusetsize,
__const cpu_set_t *__cpuset) __THROW;
(likewise for sched_getaffinity()).
Please fix this problem before Sarge goes out the door.
--david
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing')
Architecture: ia64
Kernel: Linux 2.6.11-rc2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#297769: patch
> On Fri, 08 Apr 2005 15:32:29 +0900, GOTO Masanori <[EMAIL PROTECTED]>
> said:
GOTO> I fear to change this interface until sarge release because there
GOTO> might be another packages that uses sched_setaffinity.
Well, yes, schedutils probably would need updating. I don't know of
anything else, though. We only care about the Debian packages for
sarge, I assume, right? If so, couldn't someone do a trivial find
across all sources for sched_{s,g}et_affinity? I'd be happy to
volunteer to fix all the packages that are affected (I'm not too
worried, the number will be very small, I'm sure of that).
GOTO> I tender not to include the patch. I would like to call your opinion
GOTO> about Bastian's patch.
That would really be unfortunate because it will mean that Debian is
incompatible with all other modern distributions. It's very likely
that it will cause a lot more grief down the road because new software
will break. For example, recent LMbench3 releases started to use
sched_setaffinity() and of course they use the correct (new)
interface...
--david
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292673: additional info
> On Fri, 08 Apr 2005 18:38:05 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: GOTO> OK, I pulled the Jakub's patch and built it. I put it at: GOTO> GOTO> http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-21_ia64.linuxthreads GOTO> David, could you test this glibc on your ia64 environment with GOTO> (ex) evolution? I see that Dann already has done so. If you still need me to test something, let me know. Thanks for fixing this! --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3
>>>>> On Wed, 22 Jan 2003 18:30:57 +0900, GOTO Masanori <[EMAIL PROTECTED]> said:
Goto> At Wed, 22 Jan 2003 07:27:41 +0800,
Goto> Bdale Garbee wrote:
>>
>> I don't know anything about this header file offhand... Could someone
>> investigate and give us an answer, please?
>>
>> Bdale, at Linux Conf Australia this week
>>
>>
>> From: David Mosberger <[EMAIL PROTECTED]>
>> Subject: [ia64 R&D] bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3
>>
>> It appears that Debian/stable ships with a stale header file:
>> /usr/include/bits/sigstack.h, contains:
>>
>> #define MINSIGSTKSZ2048
>> #define SIGSTKSZ 8192
>>
>> These values are far too small and should be replaced with:
>>
>> #define MINSIGSTKSZ131027
>> #define SIGSTKSZ 262144
>>
>> I think this headerfile has been corrected for "unstable" already, but
>> since this is effectively an ABI-change, it would be good to fix it in
>> "stable" too.
>>
>> Can do?
Goto> It's already in glibc-2.3.1-10.
Yes, of course. I said that much. The point is that people who use
"stable" for development work will continue to produce "bad" binaries.
That why I think it should be fixed for "stable" as well.
Goto> /* Minimum stack size for a signal handler. */
Goto> #define MINSIGSTKSZ 131027
Goto> /* System default stack size. */
Goto> #define SIGSTKSZ262144
Goto> However, I don't know why such big size is needed...
I assume you realize that these are platform-specific header files?
On ia64 (which is what we're talking about here), the values need to
be relatively big because the architecture allows for up to ~16KB of
register-state. No current ia64 chip implements that many registers,
but with the stack size, you definitely want to err on the side of
safety and make it rather too big than too small.
--david
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bad {MIN}SIGSTKSZ on debian glibc-2.2.5-14.3
> On Sat, 25 Jan 2003 18:22:38 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> Ah, I see. But... is it critical thing to replace "stable" package? GOTO> Changing Debian "stable" release is something high barrier... GOTO> I don't know current IA-64 really needs such change or not, so I GOTO> would like to know this change is "indispensable". I should say that I know next to nothing about Debian release management. Having said that: in my opinion, this is something that should be fixed at the next possible opportunity. I don't think it's worth making a release because of this fix, but it would be good if the fix could be rolled into the next update. My understanding is that there are relatively frequent "security" updates. Perhaps it could be rolled into one of those. GOTO> BTW, I would like to know that how many registers the current GOTO> IA64 (Itanium/Itanium2) has? The current chips implement the architected minimum of registers, that is, there are 96 stacked registers (for a total of 128 integer registers and 128 floating-point registers). Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: IMPORTANT glibc fix
> On Sat, 29 Mar 2003 00:14:00 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: >> Thanks. I've just updated cvs.dpatch to the latest. glibc >> 2.3.2-1 should fix this problem. Excellent. Debian beating everybody else to the punch, once again! ;-) --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: recent commit
Camm, > On 21 Aug 2003 00:52:14 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> --enable-static configuration option -- default on ia64, as a Camm> workaround for current algorithm of runtime realized function Camm> descriptors. It appears that you'd see the same/similar problem on hp-ux, so it's not just a GNU toolchain/glibc thing. Perhaps the best fix would be to dump the memory mappings for the function descriptors along with the unexec'd binary. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: recent commit
> On 28 Aug 2003 21:00:54 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings! This sounds like the sort of sidestepping of the Camm> function descriptors that I was seeking initally. Can you Camm> elaborate? I can dump the actual address, but don't I need to Camm> find where these will be in the function descriptor mapping at Camm> runtime to match the calling convention? No, they won't be remapped when starting the unexec'd binary (that's the issue, in fact, otherwise you wouldn't have a problem). Just dumping the memory areas containing the function descriptors and making them part of the unexec'd binary _ought_ to work. Camm> Am I the only one with these problems on this platform? It's the first time I heard of it. Camm> BTW, Debian hppa works fine. Yes, that's not surprising. HP-PA handles function descriptors differently (mostly in worse ways; this is one area where the HP-PA way of doing things happens to work out better). --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: recent commit
> On 29 Aug 2003 17:38:31 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings, and thanks again! So how do I find the right area Camm> before dumping? Perhaps it would work to scan /proc/self/maps for the mapping that covers the address of (any) function descriptor in the main program? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204789: [Gcl-devel] Re: recent commit
> On 05 Sep 2003 18:38:45 -0400, Camm Maguire <[EMAIL PROTECTED]> said: Camm> Greetings, and thankyou for this suggestion. It does seem like a bit Camm> of a hack though, no? It's a hack until it's used > 3 times, then it becomes a technique... ;-) Camm> Do you feel this would be more stable than just linking Camm> statically? It should be possible to make it work well, but it would require some experimentation etc. Static linking is certainly the easy way out. Camm> Apropos to this, I just saw the following warnings issued on a static Camm> build on merulo: Camm> /usr/lib/libtcl8.4.a(tclUnixFCmd.o)(.text+0x1b62): In function `GetGroupAttribute': Camm> : Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I think that's glibc telling you about nsswitch needing some shared libraries (i.e., the static binary still uses dlopen, and hence has dependencies on shared objects). If that's what it is, it's nothing new. glibc has had this feature/flaw for a long time. I think only the warning is new. Camm> Please also et me know whether you think Debian ia64 ldso Camm> might change in this regard in the future. No idea. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: FWD: IMPORTANT glibc fix
> On Sat, 29 Mar 2003 00:14:00 +0900, GOTO Masanori <[EMAIL PROTECTED]> > said: >> Thanks. I've just updated cvs.dpatch to the latest. glibc >> 2.3.2-1 should fix this problem. Excellent. Debian beating everybody else to the punch, once again! ;-) --david
Bug#225466: libc6.1: thread-creation fails after setting non-page-aligned stack limit
Package: libc6.1 Version: 2.3.2.ds1-10.0.1 Severity: normal Tags: sid patch I noticed that I can no longer load a directory via dired. The root-cause of the problem appears to be that Emacs uses setrlimit() to set RLIMIT_STACK. This limit won't be page-size-aligned in general. As a result, whenever Emacs ends up spawning a subprocess for an executable that uses NPTL, the subprocess fails with an error like this: init.c:259: __pthread_initialize_minimal_internal: Assertion `__default_stacksize % __sysconf (_SC_PAGESIZE) == 0' failed. A workaround is to start Emacs with LD_ASSUME_KERNEL=2.4.18. The proper fix is already in the CVS libc and consists of these two patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/init.c.diff?r1=1.42&r2=1.43&cvsroot=glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/init.c.diff?r1=1.40&r2=1.41&cvsroot=glibc I'd appreciate if these patches could be incorported into the Debian libc package, so that Emacs is more usable again. Note: I originally reported this problem for Emacs (see bug #224344), but it is clear now that this is really a libc problem. Thanks, --david -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux wailua.hpl.hp.com 2.6.0 #121 Fri Dec 19 10:37:07 PST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information
TLS-version of libc6/{testing,unstable} breaks libunwind
Hi, I recently noticed that with Debian/testing or Debian/unstable, many libunwind [1] checks are failing with a SEGFAULT. The root-cause of these crashes appears to be that the TLS-version of libc-2.3.2 is built with -fomit-frame-pointer on i386 (see nptl_extra_cflags in debian/sysdeps/i386.mk of the package). It would be OK to use -fomit-frame-pointer if the library provided DWARF2 unwind-info for all functions compiled in this manner. However, for some reason, the unwind-info for __libc_start_main is not present in the library. Specifically: $ nm -D /lib/tls/libc-2.3.2.so | grep __libc_start_main 000156f0 T __libc_start_main $ readelf -wf /lib/tls/libc-2.3.2.so |head -17 The section .eh_frame contains: 0014 CIE Version: 1 Augmentation: "zR" Code alignment factor: 1 Data alignment factor: -4 Return address column: 8 Augmentation data: 1b DW_CFA_def_cfa: r4 ofs 4 DW_CFA_offset: r8 at cfa-4 DW_CFA_nop DW_CFA_nop 0018 0018 001c FDE cie= pc=00015b10..00015bb9 DW_CFA_advance_loc: 3 to 00015b13 That is, even though unwind info is present in general, the first function for which there is unwind-info starts at address 0x15b10. There is no unwind-info for __libc_start_main. Because of this, it is _impossible_ to unwind safely through the call stack. What happens in the case of the failing libunwind checks is that once unwinding hits __libc_start_main, libunwind starts accessing "random" memory, because __libc_start_main doesn't maintain the frame-chain yet it also doesn't provide unwind info. The problem doesn't show with LD_ASSUME_KERNEL set to 2.4.18 (i.e., when /lib/libc-2.3.2.so is in use). Also, I checked on a Red Hat Enterprise Linux AS release 3 machine and it doesn't show the problem either. It also uses TLS-enalbed libc-2.3.2, but I suspect it was built without -fomit-frame-pointer. --david [1] http://www.hpl.hp.com/research/linux/libunwind/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
>>>>> On Fri, 20 Aug 2004 12:51:03 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> Hi David, At Thu, 19 Aug 2004 04:36:59 -0700, David Mosberger GOTO> wrote: >> I recently noticed that with Debian/testing or Debian/unstable, >> many libunwind [1] checks are failing with a SEGFAULT. The >> root-cause of these crashes appears to be that the TLS-version of >> libc-2.3.2 is built with -fomit-frame-pointer on i386 (see >> nptl_extra_cflags in debian/sysdeps/i386.mk of the package). It >> would be OK to use -fomit-frame-pointer if the library provided >> DWARF2 unwind-info for all functions compiled in this manner. >> However, for some reason, the unwind-info for __libc_start_main >> is not present in the library. Specifically: >> >> $ nm -D /lib/tls/libc-2.3.2.so | grep __libc_start_main 000156f0 >> T __libc_start_main $ readelf -wf /lib/tls/libc-2.3.2.so |head >> -17 The section .eh_frame contains: >> >> 0014 CIE Version: 1 Augmentation: "zR" Code >> alignment factor: 1 Data alignment factor: -4 Return address >> column: 8 Augmentation data: 1b >> >> DW_CFA_def_cfa: r4 ofs 4 DW_CFA_offset: r8 at cfa-4 DW_CFA_nop >> DW_CFA_nop >> >> 0018 0018 001c FDE cie= pc=00015b10..00015bb9 >> DW_CFA_advance_loc: 3 to 00015b13 >> >> That is, even though unwind info is present in general, the first >> function for which there is unwind-info starts at address >> 0x15b10. There is no unwind-info for __libc_start_main. >> >> Because of this, it is _impossible_ to unwind safely through the >> call stack. What happens in the case of the failing libunwind >> checks is that once unwinding hits __libc_start_main, libunwind >> starts accessing "random" memory, because __libc_start_main >> doesn't maintain the frame-chain yet it also doesn't provide >> unwind info. >> >> The problem doesn't show with LD_ASSUME_KERNEL set to 2.4.18 >> (i.e., when /lib/libc-2.3.2.so is in use). Also, I checked on a >> Red Hat Enterprise Linux AS release 3 machine and it doesn't show >> the problem either. It also uses TLS-enalbed libc-2.3.2, but I >> suspect it was built without -fomit-frame-pointer. GOTO> I prepared 2.3.2.ds1-16_ia64 compiling without GOTO> -fomit-frame-pointer. It's added by debian/sysdeps/linux.mk. GOTO> I put that version at: GOTO> http://www.gotom.jp/~gotom/debian/debian/glibc/2.3.2.ds1-16_ia64.fofp/ GOTO> David, could you check it? Unfortunatelly I have no GOTO> permission to access chroot on ia64 to test this kind of GOTO> problems. Thanks, but why ia64? My bug-report was for i386. There is no issue for ia64 (where omit-frame-pointer is a no-op). GOTO> I think it's good idea to drop -fomit-frame-pointer from GOTO> linux.mk for building libc with NPTL. If such optimization GOTO> option is fine for specific architecture, it should be defined GOTO> -fomit-frame-pointer in debian/sysdeps/*.mk. Does this mean you plan on rebuilding the i386 glibc without -fomit-frame-pointer? That would be fine with me. Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
> On Fri, 10 Sep 2004 12:21:04 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> I think it's good idea to drop -fomit-frame-pointer from GOTO> linux.mk for building libc with NPTL. If such optimization GOTO> option is fine for specific architecture, it should be defined GOTO> -fomit-frame-pointer in debian/sysdeps/*.mk. >> Does this mean you plan on rebuilding the i386 glibc without >> -fomit-frame-pointer? That would be fine with me. GOTO> Yes, if it makes problem, and if it does not cause GOTO> siginificant performance drop, I think it should be modified. OK, that would be good. BTW: I noticed that the Debian libc is still using the two-argument-version of sched_setaffinity(). For example: $ dpkg -s libc6-dev|fgrep Version: Version: 2.3.2.ds1-16 $ fgrep sched_setaffinity /usr/include/sched.h extern int sched_setaffinity (__pid_t __pid, __const cpu_set_t *__mask) The two-argument version of sched_setaffinity() was a mistake and the current (CVS) libc uses a 3-argument version instead: extern int sched_setaffinity (__pid_t __pid, size_t __cpusetsize, __const cpu_set_t *__cpuset) __THROW; Could the Debian-libc be updated accordingly? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
Goto, It appears the current libc (2.3.2.ds1-18) still has been copiled with omit-frame-pointer. If dropping omit-frame-pointer is not acceptable (for whatever reason), please consider adding -fexceptions instead. That way, GCC will at least add unwind-tables, so a DWARF2-capable unwinder can work. Is it possible to fix this before Debian 3.1 is released? It would be very nice, since otherwise, backtraces are hopelessly broken. Thanks, --david >>>>> On Fri, 10 Sep 2004 12:21:04 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> At Fri, 20 Aug 2004 00:26:37 -0700, David Mosberger wrote: GOTO> I prepared 2.3.2.ds1-16_ia64 compiling without GOTO> -fomit-frame-pointer. It's added by debian/sysdeps/linux.mk. GOTO> I put that version at: >> GOTO> http://www.gotom.jp/~gotom/debian/debian/glibc/2.3.2.ds1-16_ia64.fofp/ >> GOTO> David, could you check it? Unfortunatelly I have no GOTO> permission to access chroot on ia64 to test this kind of GOTO> problems. >> Thanks, but why ia64? My bug-report was for i386. There is no >> issue for ia64 (where omit-frame-pointer is a no-op). Goto> Oops. I didn't confirm which architecture was used. Plus I Goto> should know ia64 frame structure, too. GOTO> I think it's good idea to drop -fomit-frame-pointer from GOTO> linux.mk for building libc with NPTL. If such optimization GOTO> option is fine for specific architecture, it should be defined GOTO> -fomit-frame-pointer in debian/sysdeps/*.mk. >> Does this mean you plan on rebuilding the i386 glibc without >> -fomit-frame-pointer? That would be fine with me. Goto> Yes, if it makes problem, and if it does not cause Goto> siginificant performance drop, I think it should be modified. Goto> Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
> On Fri, 22 Oct 2004 11:02:22 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> But I try to build with -fomit-frame-pointer. You mean _without_ -fomit-frame-pointer, right? Goto> If it's serious for some usages, please let me know. It's definitely serious. Any application that tries to create a backtrace may crash with this libc. It's _impossible_ to get a proper backtrace if you compile with -fomit-frame-pointer without using -fexceptions (or at least -funwind-tables). Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: TLS-version of libc6/{testing,unstable} breaks libunwind
> On Thu, 28 Oct 2004 02:14:48 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: GOTO> We got security bug report; it may be chance to switch -19. Cool. I suddenly like security bugs... ;-) GOTO> I put no -fomit-frame-pointer .deb based on -18 at: GOTO> http://www.gotom.jp/~gotom/debian/glibc/2.3.2.ds1-18_i386.fofp/ OK, I tried this on an x86 laptop and it does indeed fix the libunwind failures that were due to -fomit-frame-pointer/lack-of-unwind-info. Thanks! --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> Is the patch in #278836 a prerequisite for the above Matthias> changes, or can it be done without it? If the gas-patch isn't applied, you run the risk of getting wrong unwind-info into object-files. For GCC proper, that shouldn't matter but it could be an issue for the libraries generated by GCC. It's not all that common to get frame-pointer-relative info on ia64, which is the only case that's affected, so I suppose we could check the affected libraries for such info (assuming we can generate a list of affected libraries). Matthias> Same question for #278837. The hunk for file ptl/sysdeps/unix/sysv/linux/ia64/pt-initfini.c is definitely needed. The other hunks are needed only when building glibc with a GCC which has a dependency on -lunwind. Matthias> As an alternative, revert the libunwind patch. Which patch are you referring to here? My main concern is to ensure that the toolchain generates correct unwind-info. That question is independent of whether or not -lunwind is used by GCC, so I hope we can achieve the former even if the latter is out of scope at the moment. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> From my point of view we can get around with it by Matthias> including the libunwind shared library in libgcc1 for the Matthias> sarge release. I'm worried about the version skew of the Matthias> unwind lib ib 0.98.3 and GCC-3.4.3. There's one Matthias> additional library in libunwind. Do you mean libunwind-ia64.so.7.0.0? That one won't be needed by anything related to GCC (or, more generally, local unwinding). Having said that, the most recent GDBs have a soft dependency on libunwind-ia64.so: they'll try to dlopen libunwind-ia64.so and if that doesn't succeed, fall back on code-reading (which is very unreliable, but better than nothing at all). Other than GDB, I can't think of any Debian packages that would currently rely in libunwind-ia64. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: -19 FTBFS on ia64
> On Tue, 7 Dec 2004 09:10:13 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> I assume the link line should read Matthias> -lunwind -lgcc -lgcc_eh Matthias> instead of Matthias> -lgcc -lgcc_eh I already submitted a patch for this (based on a patch by HJ Lu) and GOTO said he would incorporate it. Perhaps that hasn't happened yet? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
> On Thu, 9 Dec 2004 12:49:38 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> ok, I'm currently bootstrapping gcc-3.3 with the patch Matthias> attached, a glibc bootstrap using this compiler did Matthias> succeed. I'll upload the fixed gcc-3.3, when bootstrap and Matthias> testsuite finishes. Matthias> -LIB2ADDEH = $(srcdir)/unwind-libunwind.c $(srcdir)/unwind-sjlj.c \ Matthias> - $(srcdir)/unwind-c.c Matthias> +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c Looks reasonable to me. I'm still not clear why unwind-c.c isn't needed on HP-UX, but that's a separate issue. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
> On Thu, 9 Dec 2004 13:35:07 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> works ok until building glibc with the just built Matthias> compiler. _Unwind_Resume, _Unwind_GetRegionStart are Matthias> referenced by glibc objects, _Unwind_GetIP, _Unwind_SetGR, Matthias> _Unwind_SetGR, _Unwind_SetIP are referenced by Matthias> libgcc_eh.a. Found in the standalone libunwind.a: Matthias> g F .text 0060 .protected _Unwind_GetRegionStart Matthias> *UND* _ULia64_get_proc_info Matthias> g F .text 0060 __libunwind_Unwind_GetRegionStart Matthias> a quick fix is to undefine the PROTECTED macro in Matthias> unwind-0.98.3, surely not the right thing to do? A protected symbol is still globally visible, it's just that references from within the library will be bound within the library itself, so I don't understand why this would be needed. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
Hi Matthias, > On Sun, 12 Dec 2004 17:55:57 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> with the patch attached and an updated gcc-3.3 package, Matthias> libunwind support for ia64 seems to work for me. I Matthias> couldn't install any of the built packages. I'd like to Matthias> ask people to install the test builds found at Matthias> http://people.debian.org/~doko/glibc/ Matthias> http://people.debian.org/~doko/gcc-3.3/ Matthias> and stress test these packages. I wanted to try this but found that the gcc-3.3 has a libgcc1 package for hppa only. Is this intentional? I thought a new libgcc1 package for ia64 was needed so we pick up the libunwind built from the libunwind sources. Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
> On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> please get the libgcc1 package from the unstable Matthias> distribution. I think I've got that one already (libgcc1 v3.4.3-2). Matthias> It's currently built by the gcc-3.4 sources and includes Matthias> the libunwind.so.7 shared library. The libunwind.so.7 in libgcc1 v3.4.3-2 appears to be built from the GCC sources. Is that what you had in mind? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
>>>>> On Tue, 14 Dec 2004 11:58:07 +0100, Matthias Klose <[EMAIL PROTECTED]> >>>>> said: Matthias> David Mosberger writes: >> >>>>> On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose >> <[EMAIL PROTECTED]> said: Matthias> It's currently built by the gcc-3.4 sources and includes Matthias> the libunwind.so.7 shared library. >> The libunwind.so.7 in libgcc1 v3.4.3-2 appears to be built from >> the GCC sources. Is that what you had in mind? Matthias> yes, based on your statement that both versions would Matthias> do. it's possible to include the libunwind source in the Matthias> gcc-3.4 source and build the libunwind7 package from that Matthias> source. Now I'm confused. I thought that after running into the libunwind build-failures, you decided to replace the GCC-based libunwind with the one from the libunwind package. I just checked and with the current packaging, I'm still getting failures during the libunwind build. For example: : gcc -g -O -fexceptions -Wall -Wsign-compare -o .libs/Lperf-simple Lperf-simple.o ../src/.libs/libunwind-ia64.so Gperf-simple.o(.text+0x32): In functionLperf-simple.o(.text+0x32): In function `measure_unwind': ../../libunwind/tests/Gperf-simple.c:64: undefined reference to `_Uia64_getcontext' : Did you fix this issue in some other way? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: status of libunwind patches for ia64
>>>>> On Wed, 15 Dec 2004 13:55:45 -0800, David Mosberger <[EMAIL PROTECTED]> >>>>> said: David> I just checked and with the current packaging, I'm still David> getting failures during the libunwind build. After fixing these problems in libunwind, I can successfully run "make check" in libunwind: PASS: test-proc-info PASS: test-static-link PASS: test-strerror PASS: Gtest-bt PASS: Ltest-bt PASS: Gtest-exc PASS: Ltest-exc PASS: Gtest-init PASS: Ltest-init PASS: Gtest-concurrent PASS: Ltest-concurrent PASS: Gtest-resume-sig PASS: Ltest-resume-sig PASS: Gtest-dyn1 PASS: Ltest-dyn1 PASS: test-async-sig PASS: test-flush-cache PASS: test-init-remote PASS: test-mem PASS: test-setjmp PASS: test-ptrace PASS: Gia64-test-stack PASS: Lia64-test-stack PASS: Gia64-test-nat PASS: Lia64-test-nat PASS: Gia64-test-rbs PASS: Lia64-test-rbs PASS: Gia64-test-readonly PASS: Lia64-test-readonly PASS: ia64-test-setjmp PASS: ia64-test-sig PASS: run-check-namespace PASS: run-ptrace-mapper PASS: run-ptrace-misc PASS: run-ia64-test-dyn1 === All 35 tests passed === That's great! First time this happens! So, I think we have two options: (1) leave GCC package as it is and make a libunwind v0.98.4 release which fixes the above-mentioned problems (2) change GCC package to include the libunwind version from the libunwind package I think (1) makes more sense _provided_ that in the not too distant future, we can fix the packaging such that /lib/libunwind.so.7 is provided by the libunwind package. Without that, gdb won't be able to unwind dynamically generated code and, IIRC, there are additional gcj failures, which starts to matter, now that gij is being used for providing Java applet functionality inside ia64 browsers. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR
> On Thu, 18 Sep 2003 08:09:33 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> Yes, it's not libc6 own problem, but kernel source problem. Goto> In some kernels, this problem should also be occured on alpha. Goto> One way to fix is to enclose #ifdef __KERNEL__. Goto> David, could you look this namespace pollution issue? at: Goto> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210359 Goto> This experimental patch is for 2003-09-17 bk latest. Only Goto> ia64 part. Is this ok? Is this CONFIG_IA64_HP_SIM part still Goto> needed for debugging purpose? Goto> --- include/asm-ia64/param.h 2002-10-07 13:20:02.0 Goto> +0900 +++ include/asm-ia64/param.h.new 2003-09-17 Goto> 19:13:34.0 +0900 @@ -8,6 +8,8 @@ * David Goto> Mosberger-Tang <[EMAIL PROTECTED]> */ Goto> +#ifdef __KERNEL__ + #include Goto> #ifdef CONFIG_IA64_HP_SIM @@ -20,6 +22,8 @@ # define HZ 1024 Goto> #endif Goto> +#endif + #define EXEC_PAGESIZE 65536 Goto> #ifndef NGROUPS Goto> Regards, -- gotom Looks like a nasty problem. If we can't include , there is no guarantee that the header contents will be correct. We can obviously move the definition of HZ into the (existing) __KERNEL__-only section, but then apps which rely on the HZ macro won't compile anymore. Perhaps that's OK (they probably should use sysconf() anyhow), though. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR
> On Thu, 18 Sep 2003 09:33:47 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> Adding HZ=1024 for userland seems ok for me even if CONFIG_IA64_HP_SIM Goto> is defined, but any problems? Yeah, but it just looks so warty... Are there any Debian packages that break if HZ is not defined by param.h? --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#210359: kernel CONFIG_TR interferes with busybox CONFIG_TR
>>>>> On Thu, 18 Sep 2003 10:23:48 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> At Wed, 17 Sep 2003 17:37:02 -0700, Goto> David Mosberger wrote: >> >>>>> On Thu, 18 Sep 2003 09:33:47 +0900, GOTO Masanori <[EMAIL PROTECTED]> said: Goto> Adding HZ=1024 for userland seems ok for me even if CONFIG_IA64_HP_SIM Goto> is defined, but any problems? >> Yeah, but it just looks so warty... >> Are there any Debian packages that break if HZ is not defined by param.h? Goto> Quick check on my machine, one example is strace 4.4.96 syscall.c. I Goto> guess HZ is still needed by many packages... Uh, this is difficult Goto> problem. Well, apparently using HZ in user applications is bad, but Goto> it has been used for a long time. OK, thanks for checking. It does sound like we have to resort to the "warty" solution, then. I'll fix the 2.6 tree accordingly. Thanks, --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#225466: libc6.1: thread-creation fails after setting non-page-aligned stack limit
Package: libc6.1 Version: 2.3.2.ds1-10.0.1 Severity: normal Tags: sid patch I noticed that I can no longer load a directory via dired. The root-cause of the problem appears to be that Emacs uses setrlimit() to set RLIMIT_STACK. This limit won't be page-size-aligned in general. As a result, whenever Emacs ends up spawning a subprocess for an executable that uses NPTL, the subprocess fails with an error like this: init.c:259: __pthread_initialize_minimal_internal: Assertion `__default_stacksize % __sysconf (_SC_PAGESIZE) == 0' failed. A workaround is to start Emacs with LD_ASSUME_KERNEL=2.4.18. The proper fix is already in the CVS libc and consists of these two patches: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/init.c.diff?r1=1.42&r2=1.43&cvsroot=glibc http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/nptl/init.c.diff?r1=1.40&r2=1.41&cvsroot=glibc I'd appreciate if these patches could be incorported into the Debian libc package, so that Emacs is more usable again. Note: I originally reported this problem for Emacs (see bug #224344), but it is clear now that this is really a libc problem. Thanks, --david -- System Information: Debian Release: testing/unstable Architecture: ia64 Kernel: Linux wailua.hpl.hp.com 2.6.0 #121 Fri Dec 19 10:37:07 PST 2003 ia64 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6.1 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
