Bug#934080: [libc6] Significant degradation in the memory effectivity of the memory allocator
On Wed, Aug 7, 2019 at 2:12 AM Roman Savochenko wrote: > So, we have got such regression, and I have to think about back-using > Debian 7 on such sort dynamic environments and forget all new ones. :( > The primary thing to determine is if this extra memory is due to application demand or not. To determine that I usually use a set of malloc tracing utilities: https://pagure.io/glibc-malloc-trace-utils These let you capture the direct API calls and graph the application demand, which you can compare to the real usage. Then you can take your trace of malloc API calls, which represents your workload, and run it in the simulator with different tunable parameters to see if they make any difference or if the simulator reproduces your excess usage. If it does then you can use the workload and the simulator as your test case to provide to upstream glibc developers to look at the problem. Cheers, Carlos.
Bug#874160: Fedora has C.UTF-8
On Tue, Nov 6, 2018 at 4:30 AM Adam Borowski wrote: > > Looks like Fedora has C.UTF-8 now, and even backported this change to their > stable releases: > > https://bugzilla.redhat.com/show_bug.cgi?id=902094 > > They're not upstream, but a good part of distros that are not downstream > from Debian are downstream from Fedora. This availability makes defaulting > to C.UTF-8 that more viable. I'm working to get C.UTF-8 upstream, but there are real defects in full code-point sorting that need resolution. https://sourceware.org/bugzilla/show_bug.cgi?id=17318 I think all distros should start trying to use a C.UTF-8 that is installed and unremovable. Particularly since Python3 and gnome-terminal need UTF-8. Cheers, Carlos. > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road? For thousands of years, the > ⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the > ⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk. To where it came > ⠈⠳⣄ together with silk (judging by today's amber stalls). >
Bug#895981: please cleanup /var/cache/nscd on restart
On Sun, Apr 29, 2018 at 2:56 PM, Florian Weimer wrote: > * Harald Dunkel: > > > I am using both systemd and sysvinit-core, but I am not sure which one > > was active when I ran into this problem. > > > > Consider a split DNS setup for a remote network. I had started an IPsec > > connection to the remote side. /etc/resolv.conf was changed to include > > the new internal DNServer on the remote side, but a host lookup gave me > > still the old external address. Stopping nscd did not help, AFAIR. > > That's arguably a bug in nscd. It should flush the cache each time it > detects a change in /etc/resolv.conf (or /etc/gai.conf, for that > matter). > And it does, this is what define_traced_file/init_traced_file do in nss/nss_files/files-init.c. Then via the nscd callback nscd_init_cb, we call register_traced_file for each loaded database. Then each registered file, like /etc/resolv.conf, is watched via inotify for any changes, and if a change is detected and finfo->call_res_init was true (and it's true only for resolv.conf) then we call res_init(). We do not handle anything for changes in gai.conf, we would have to add that. Cheers, Carlos.
Bug#888073: glibc: Support amd64 systems without /lib64
On Wed, Jan 24, 2018 at 9:26 AM, Aurelien Jarno wrote: > On 2018-01-24 17:08, Javier Serrano Polo wrote: >> Source: glibc >> Version: 2.26-4 >> Severity: wishlist >> >> amd64 systems can work perfectly without a /lib64 directory. Since I am >> unlikely to convince you to ship ld-linux-x86-64.so.2 under /lib instead > > I am not convinced about that. The dynamic linker path is part of the > x86-64 ABI and is present in all ELF executables. Moving it means > rebuilding all the packages. It should probably be done using a > different architecture than "amd64". > > Could you please explain it how it works and what would be the use case? The dynamic loader cannot be moved, it is an ABI artifact, as you rightly state. In Fedora we had the UsrMove project: https://fedoraproject.org/wiki/Features/UsrMove So there is a symlink from /lib64 to /usr/lib64, that's the best you can do IMO. Cheers, Carlos.
Bug#867283: Crash in glibc's mktime in low-memory situations
On Wed, Jul 5, 2017 at 1:43 PM, Johannes Schultz wrote:
>
>> None of the internal assertions in tzfile.c have to do with low
>> memory, they have to do with logical consistency and expected
>> outcomes.
>
> Okay, so let's look at the stack trace again and where it failed.
> The failing line 779 in __tzfile_compute is:
>
> if (__tzname[0] == NULL)
> {
> assert (num_types == 1); // <-- boom
>
> So, where is __tzname[0] being set? Depending on the path taken, it can be
> either of these:
>
> line 627: __tzname[0] = NULL; // initial value
> line 646: __tzname[0] = __tzstring (&zone_names[types[i].idx]);
> line 686: __tzname[0] = __tzstring (zone_names);
> line 756: __tzname[dst] = __tzstring (&zone_names[idx]);
>
> Internally, __tzstring calls malloc. If malloc fails, it returns NULL.
> So it is entirely possible that this assertion will fail because of an
> out-of-memory situation.
Perfect, in which case it *should* be fixed to make this more robust in the
face of low memory.
> No of course this is bad, but so far the integrity has not been compromised.
Agreed.
> It just means that the function really should return with an error now. As
> far as I can see there are currently no facilities for returning an error in
> this particular function, but I guess it really should be able to propagate
> allocation failures to the library functions that call it, so that those can
> return an error to the user (if that is part of their API contract, that
> is).
I agree.
If you have the opportunity please file a match bug with upstream at
sourceware.org/bugzilla. That way upstream is made aware of the issue.
As far as I can see we probably need to fix all cases of __tzstring returning
NULL and do something appropraite. It only ever returns NULL on ENOMEM.
Cheers,
Carlos.
Bug#867283: Crash in glibc's mktime in low-memory situations
On Wed, Jul 5, 2017 at 9:13 AM, Johannes Schultz wrote: > mktime is supposed to return -1 and, according to cplusplus.com, has a > no-throw guarantee for C++ code. So even if some internal memory cannot be > allocated, I expect mktime to return with an error value and not cause a > SIGABRT. > I found it difficult to reproduce this outside my afl-instrumented > environment, but I hope the stack trace helps with verifying whether this is > a valid bug. If you need a test case to reproduce, let me know. If an internal assertion in tzfile.c triggers then it means that the integrity of the library is compromised. None of the internal assertions in tzfile.c have to do with low memory, they have to do with logical consistency and expected outcomes. I've reviewed tzfile.c, tzset.c, and mktime.c and it's hard for me to see what low-memory path could trigger the assertion. One possible hypothesis is that your program is corrupting library data given certain AFL input. You will have to review your AFL input in more detail to see why it is causing a SIGABRT. In general the library should not SIGABRT for normal conditions like low-memory. I agree that if you find that is *really* the case, then we can fix this upstream. Cheers, Carlos.
Bug#816742: libc6: sem_post/sem_wait not working for 32bit to 64bit inter-process communication
On Sat, Mar 5, 2016 at 7:28 AM, Aurelien Jarno wrote: > control: forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=17980 Semaphore interoperability between two different ABIs has never been supported. It worked because you were lucky and the implementation was flawed. To fix the implementation flaws (which are real), we've had to adopt slightly different algorithms for 32-bit and 64-bit. Cheers, Carlos.
Bug#815974: Segmentation fault in libresolv triggered by php5-fpm
On Fri, Feb 26, 2016 at 7:46 AM, Fabian Niepelt wrote: > This is the correct output, the older one contains a test I thought was > in an endless loop but succeeded after a few minutes. The glibc maintainers for debian need to review those failures. They indicate serious deviation from expected behaviour. At the very least the bug 18665* tests should not fail. However, the tests are sensitive to response order. -address: STREAM/TCP 10.0.3.6 80 -address: STREAM/TCP 2001:db8::4:6 80 +error: Name or service not known This is a weird failure. Cheers, CArlos.
Bug#815974: Segmentation fault in libresolv triggered by php5-fpm
On Fri, Feb 26, 2016 at 3:57 AM, Fabian Niepelt wrote: > I'll be gladly providing additional info if you require it. > Program received signal SIGSEGV, Segmentation fault. > 0x7f146545e4fa in *__GI___libc_res_nsearch (statp=0x7f14659f7300, > name=, class=, type=, > answer=0x7fff6d6c0df0 "2", anslen=, > answerp=0x7fff6d6c1660, > answerp2=0x7fff6d6c1658, nanswerp2=0x7fff6d6c167c, > resplen2=0x7fff6d6c1678, answerp2_malloced=0x20032) at > res_query.c:393 > 393 res_query.c: No such file or directory. 1) Download the tarball from the official CVE-2015-7547 tests here: https://sourceware.org/ml/libc-alpha/2016-02/msg00418.html 2) Comment out BUILDDIR (to build against your system libraries) 3) Run 'make' to build the test, and run them all one-by-one. Do any of them fail on your system? Cheers, Carlos.
Bug#793641: glibc: too few static TLS slots
On Mon, Nov 23, 2015 at 7:04 AM, Aurelien Jarno wrote: > On 2015-08-17 15:04, Carlos O'Donell wrote: >> On Sun, Aug 16, 2015 at 12:48 PM, Andreas Cadhalpun >> wrote: >> >> until there's a better tested and working way to transition >> >> to ffmpeg? >> > >> > This really doesn't have that much to do with the transition to ffmpeg. >> > Any other library that (indirectly) links against sufficiently many >> > STATIC_TLS using ones and is used in some plugin is also affected. >> > >> > Note that there are currently 14 STATIC_TLS slots and gst-libav uses 6, >> > while it used 4 previously. It is a mere coincidence that this increase >> > causes totem to hit the arbitrary limit in glibc. >> >> The math can't be done that easily, it's actually a heuristic, but >> pretend it works this way for the sake of this discussion. >> >> The only immediate solution is for debian's glibc to increase >> DTV_SURPLUS to 32 or higher. This is exactly what I did for Fedora. >> >> The other alternative is to backport Alex's fixes for Sourceware bugs >> BZ #17090, BZ #17620, BZ #17621, BZ #17628, which corrects the >> heuristics behind DTV_SURPLUS which prevent the loading of STATIC_TLS. > > I have backported these patches to 2.21. Unfortunately they now cause > nptl/tst-cancel24-static to fail on at least armhf, armel, mips and > mipsel. The binary segfaults. Please submit a bug for this. Is it segfaulting when accessing locales for the first time in the newly dlopen'd libc.so.6? There are several known issues regarding statically linked and dlopened binaries that may impact this. > According to the wiki [1], the failure seems to be a known issue > in the 2.22 release, though its cause was marked as unknown. Do you know > by chance if the problem has been fixed or addressed in the meantime? No, nobody has fixed this upstream. Any triage you can provide would be appreciated. Cheers, Carlos.
Bug#737079: nscd crashes on netgroup lookups
On Wed, Oct 14, 2015 at 4:28 PM, Arthur de Jong wrote: > On Wed, 2015-10-14 at 07:56 +, Mike Gabriel wrote: >> The Debian Edu team heavily relies on NIS netgroups coming from >> LDAP. So any help with this in Debian jessie is highly appreciated!!! > > The last time I looked at nscd code I was not very happy ;) Also, nscd > has a long history of instability and returning incorrect results. The upstream glibc community has been working hard to rectify these issues, and Red Hat in particular spent a lot of time making the netgroup caching as bullet-proof as possible. If you have real bugs, please file them upstream and come talk to the community. > Btw, if anyone thinks this is something that libnss-ldapd does wrong, > please let me know. Not all NSS interfaces are consistent in terms of > memory management, return codes, etc. so there could be something > wrong. They should be consistent. Again, if you find something wrong, please file a bug. The upstream glibc community is radically different now and certainly more accepting of discussions on these issues. Cheers, Carlos.
Bug#794222: Missing patch
On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno wrote: >> So this is IMO, the wrong thing to do. You should push the patch into >> upstream 2.19 stable and rebase instead of keeping the patch in debian >> svn. Given the patch is already in upstream master it is OK to commit >> to 2.19 stable, and post to libc-stable stating you checked in this >> fix. That way debian gets broader testing of the patches we are using >> instead of the narrower "just debian" users. > > If it is fine to push this kind of patch in this branch, I would > certainly do that. I also backported for debian patch b0a3c164. Would > it be possible to also push it to the branch? If the patch doesn't change API/ABI, and it was accepted for master, then it's perfectly acceptable to push to 2.19 stable branch. You post your commit email to libc-stable so other maintainers know why you're pushing the patch. You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body: Cherry picked fix for the ppc64le bug X into 2.19. Following the usual cherry pick process: https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch Then you're done. The 2.19 branch is a rolling stable release from which you can rebase your own distro branches, either external (on sourceware) or internal (in your own repos in the distro). Cheers, Carlos.
Bug#794222: Missing patch
On Mon, Aug 17, 2015 at 7:06 PM, Carlos O'Donell wrote: > On Mon, Aug 17, 2015 at 4:34 PM, Aurelien Jarno wrote: >>> So this is IMO, the wrong thing to do. You should push the patch into >>> upstream 2.19 stable and rebase instead of keeping the patch in debian >>> svn. Given the patch is already in upstream master it is OK to commit >>> to 2.19 stable, and post to libc-stable stating you checked in this >>> fix. That way debian gets broader testing of the patches we are using >>> instead of the narrower "just debian" users. >> >> If it is fine to push this kind of patch in this branch, I would >> certainly do that. I also backported for debian patch b0a3c164. Would >> it be possible to also push it to the branch? > > If the patch doesn't change API/ABI, and it was accepted for master, > then it's perfectly acceptable to push to 2.19 stable branch. > > You post your commit email to libc-stable so other maintainers know > why you're pushing the patch. > > You'd post a Subject:[COMMITTED] 2.19: Fix blah blah blah, Body: > Cherry picked fix for the ppc64le bug X into 2.19. > > Following the usual cherry pick process: > https://sourceware.org/glibc/wiki/GlibcGit#Cherry_Pick_Changes_From_Another_Branch > > Then you're done. The 2.19 branch is a rolling stable release from > which you can rebase your own distro branches, either external (on > sourceware) or internal (in your own repos in the distro). Please make sure to merge the ChangeLog and NEWS though, and start a new 2.19.1 NEWS section if it isn't started. That way if someone wants to cut a release they can. Though the intent is never to cut a release and always roll the branches and let distros rebase. c.
Bug#793641: glibc: too few static TLS slots
On Sun, Aug 16, 2015 at 12:48 PM, Andreas Cadhalpun wrote: >> until there's a better tested and working way to transition >> to ffmpeg? > > This really doesn't have that much to do with the transition to ffmpeg. > Any other library that (indirectly) links against sufficiently many > STATIC_TLS using ones and is used in some plugin is also affected. > > Note that there are currently 14 STATIC_TLS slots and gst-libav uses 6, > while it used 4 previously. It is a mere coincidence that this increase > causes totem to hit the arbitrary limit in glibc. The math can't be done that easily, it's actually a heuristic, but pretend it works this way for the sake of this discussion. The only immediate solution is for debian's glibc to increase DTV_SURPLUS to 32 or higher. This is exactly what I did for Fedora. The other alternative is to backport Alex's fixes for Sourceware bugs BZ #17090, BZ #17620, BZ #17621, BZ #17628, which corrects the heuristics behind DTV_SURPLUS which prevent the loading of STATIC_TLS. Without Alex's fixes the implementation is limited, by a heuristic, to a limited number of libraries with STATIC_TLS, and after Alex's fixes (available in glibc 2.22) the limit is "You may load as many STATIC_TLS libraries as long as you have static image space for all of them" (which is a much higher arbitrary limit). Cheers, Carlos.
Bug#794222: Missing patch
On Sat, Aug 15, 2015 at 4:31 AM, Aurelien Jarno wrote: > control: fixed -1 glibc/2.21-0experimental0 > > On 2015-08-14 18:28, Tulio Magno Quites Machado Filho wrote: >> I believe Debian is missing the following patch for ppc64el: >> https://sourceware.org/git/?p=glibc.git;a=commit;h=a53fbd8e6cd2f69bdfa3431d616a5f332aea6664 > > I have just committed a fix to our SVN in the stable branch. If accepted > by the Debian stable release manager, we plan to have it in the next > stable point release. > > Given this bug is fixed in the experimental branch, I am marking it as > fixed for this version. So this is IMO, the wrong thing to do. You should push the patch into upstream 2.19 stable and rebase instead of keeping the patch in debian svn. Given the patch is already in upstream master it is OK to commit to 2.19 stable, and post to libc-stable stating you checked in this fix. That way debian gets broader testing of the patches we are using instead of the narrower "just debian" users. Cheers, Carlos.
Bug#794222: Missing patch
On Fri, Aug 14, 2015 at 5:28 PM, Tulio Magno Quites Machado Filho wrote: > I believe Debian is missing the following patch for ppc64el: > https://sourceware.org/git/?p=glibc.git;a=commit;h=a53fbd8e6cd2f69bdfa3431d616a5f332aea6664 Really what should be happening here is that we should backport that patch to 2.19 stable branch and ask debian to rebase? I'd like to see more distros rebase on the stable branches, that way you don't have to backport these fixes into every distro. Cheers, Carlos.
Bug#792921: [sparc64] linking against libx264 crashes runtime linker
On Tue, Jul 21, 2015 at 2:49 PM, Andreas Cadhalpun wrote: > On 20.07.2015 17:18, Carlos O'Donell wrote: >> On Mon, Jul 20, 2015 at 3:35 AM, Andreas Cadhalpun >> wrote: >>> Program received signal SIGBUS, Bus error. >>> 0xf801cda4 in elf_dynamic_do_Rela (skip_ifunc=, >>> lazy=0, nrelative=, relsize=, >>> reladdr=, map=0xf80100023570) at do-rel.h:111 >> >> Usually a corrupted library. Check md5sums. > > I don't think this problem is caused by a corrupted libx264. > > First, it's also happening on the sparc64 buildds, see e.g. [1]. > Second, I rebuilt the current x264 locally and it shows the same problem. Does the problem always reproduce or just sometimes? If it's just sometimes then it's much much harder to figure out what's wrong. You'll need a dedicated person to track down exactly what is the concurrency issue and why it's failing. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#792921: [sparc64] linking against libx264 crashes runtime linker
On Mon, Jul 20, 2015 at 3:35 AM, Andreas Cadhalpun wrote: > Program received signal SIGBUS, Bus error. > 0xf801cda4 in elf_dynamic_do_Rela (skip_ifunc=, > lazy=0, nrelative=, relsize=, > reladdr=, map=0xf80100023570) at do-rel.h:111 Usually a corrupted library. Check md5sums. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
I disagree. IMO the most flexible approach is for glibc to stop using cpuid for RTM detection and rely on the kernel to tell it if RTM is usable. Then we have a single hardware blacklist in the kernel. We need to talk to kernel people about this. Not to mention we might extend a getauxval-type API to prevent applications from using cpuid directly e.g. create a platform header for this with an x86 specific feature interface. c.
Bug#762455: libc6: SIGSEV in _dl_signal_error() (dl-error.c:94)
On Mon, Sep 22, 2014 at 8:48 AM, Pierre Schweitzer wrote: > When trying to install the latest release of Intel Parallel Studio 2015 onto > Debian testing, > I'm facing a segfault. Using GDB, I could isolate the segfault in: > _dl_signal_error (errcode=errcode@entry=0, objname=objname@entry=0x18147760 > "/tmp/install.ywPV4B/activation/activation.so", > occation=occation@entry=0x77df64eb "symbol lookup error", > errstring=errstring@entry=0x7ffecab0 "undefined symbol: > pthread_once") at dl-error.c:94 > > Here is the complete GDB output (with a backtrace): You're gettting a crash loading the proprietary 3rd party licensing code from FlexNet Publisher from Flexera Software. That platform AFAIK supports only 64-bit CentOS or RHEL, and you are therefore running on an unsupported platform. I would suggest contacting Intel to get support. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh wrote: > On Fri, 19 Sep 2014, Carlos O'Donell wrote: >> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh >> wrote: >> > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote: >> >> I can live with that, and I think I can prepare a patch if you want me to. >> > >> > Here's a minimal patch to glibc that should do it (compile tested). >> >> The GNU C Library only uses elision if built with --enable-lock-elision=yes. >> >> All you need to do is not build glibc with this flag. > > Given Jessie's expected lifetime, I'd say the blacklist is a much better > choice with the data currently available. Why not ignore this, call it a hardware problem, and let users update the microcode if their devices are broken? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh wrote: > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote: >> I can live with that, and I think I can prepare a patch if you want me to. > > Here's a minimal patch to glibc that should do it (compile tested). The GNU C Library only uses elision if built with --enable-lock-elision=yes. All you need to do is not build glibc with this flag. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758911: libc6-dev: spurious sign-conversion warning for setrlimit, clang 3.5, _GNU_SOURCE
On Fri, Aug 22, 2014 at 3:23 PM, Zack Weinberg wrote:
> glibc changes the signature of setrlimit() when _GNU_SOURCE is defined, "to
> provide better error checking":
>
> extern int setrlimit (int, const struct rlimit *); // as specified by POSIX
> extern int setrlimit (__rlimit_resource_t, const struct rlimit *); //
> _GNU_SOURCE
>
> where __rlimit_resource_t is an enum with no negative values. This causes
> some
> compilers (e.g. clang-3.5) to give spurious warnings for programs that pass
> non-constant values to setrlimit(), e.g.
>
> $ cat test.c
> #define _GNU_SOURCE
> #include
> int foo(int rsrc, struct rlimit *rl)
> {
> return setrlimit(rsrc, rl);
> }
> $ clang-3.5 -Wsign-conversion -c test.c
> test.c:5:20: warning: implicit conversion changes signedness: 'int' to
> '__rlimit_resource_t' (aka 'enum __rlimit_resource')
> [-Wsign-conversion]
> return setrlimit(rsrc, rl);
> ~ ^~~~
>
> I don't think it's reasonable for me to have to work around this in my code,
> and indeed I don't see that there _is_ any workaround available to me in C.
> (Maybe in C++ some template black magic to extract "the type of the first
> argument to setrlimit"? Yech.)
I agree.
It isn't reasonable for users to have to work around this. Please file
a bug with clang and ask them to come work with with upstream glibc to
help provide better error checking and remove the spurious warning for
this case.
> I'm labeling this a libc bug rather than a clang bug because, if libc is going
> to deviate from the standard "to provide better error checking", it needs to
> ensure that standard-compliant code still works with no complaints, even at
> quite aggressive warning levels.
My opinion is that this is not a libc bug and I would suggest
debian-glibc close this bug. You deviated from the standard the second
you defined _GNU_SOURCE. If you want POSIX, but define _GNU_SOURCE,
and then complain it's not *exactly* POSIX then I don't see what we
did wrong. At best this is an enhancement: "Be more POSIX-like if I
define _GNU_SOURCE and happen to be using clang."
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742925: eglibc: CVE-2013-4357
Related commits the fix the CVE: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=f2962a71959fd254a7a223437ca4b63b9e81130c https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=34a9094f49241ebb72084c536cf468fd51ebe3ec On Fri, Mar 28, 2014 at 9:21 PM, Michael Gilbert wrote: > package: src:eglibc > severity: important > version: 2.11.3-4 > > A stack overflow issue was reported in eglibc: > https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-4357 > > Best wishes, > Mike > > > -- > To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > Archive: > https://lists.debian.org/CANTw=MP=0e4c4es-0frtkujw9qmdpcsxp0xjpxdww9nmcag...@mail.gmail.com > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#722348: same problem
On Thu, Feb 20, 2014 at 7:23 AM, Philipp Marek wrote: > Feb 20 10:36:57 cacao kernel: [ 5299.252749] traps: ld-linux-x32.so[25723] > general protection ip:f7744eed sp:ff7fcec8 error:0 in > ld-2.17.so[f772e000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.296045] traps: ld-linux-x32.so[25737] > general protection ip:f7703eed sp:ffc83fd8 error:0 in > ld-2.17.so[f76ed000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.374231] traps: ld-linux-x32.so[25751] > general protection ip:f7790eed sp:ffa9abe8 error:0 in > ld-2.17.so[f777a000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.393666] traps: ld-linux-x32.so[25765] > general protection ip:f770feed sp:ffb3fea8 error:0 in > ld-2.17.so[f76f9000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.416296] traps: ld-linux-x32.so[25779] > general protection ip:f7782eed sp:ffec50c8 error:0 in > ld-2.17.so[f776c000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.434557] traps: ld-linux-x32.so[25793] > general protection ip:f7757eed sp:ffa995e8 error:0 in > ld-2.17.so[f7741000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.452398] traps: ld-linux-x32.so[25807] > general protection ip:f7746eed sp:ffa44b88 error:0 in > ld-2.17.so[f773+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.470434] traps: ld-linux-x32.so[25821] > general protection ip:f77d7eed sp:ffb0f978 error:0 in > ld-2.17.so[f77c1000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.495999] traps: ld-linux-x32.so[25835] > general protection ip:f77f0eed sp:ffea4908 error:0 in > ld-2.17.so[f77da000+21000] > Feb 20 10:36:57 cacao kernel: [ 5299.513835] traps: ld-linux-x32.so[25849] > general protection ip:f779feed sp:ffeaba48 error:0 in > ld-2.17.so[f7789000+21000] > Feb 20 10:37:03 cacao kernel: [ 5305.553176] do_general_protection: 38 > callbacks suppressed > > > Any ideas how to find out which program that is? You need to hack the kernel to print the argv passed to the loader. That's the only way to know what the loader was trying to load when it crashed. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#737079: nscd crashes on netgroup lookups
On Wed, Jan 29, 2014 at 5:46 PM, Arthur de Jong wrote: > Package: nscd > Version: 2.17-97 > Severity: important > > I can reasonably consistently crash nscd with netgroup lookups. Below is > the simplest configuration I can reproduce this with: The caching for netgroups has several bugs which we are trying to fix upstream. The only way this is going to get better for debian is to track all of the upstream fixes. Right now I'd say you disable caching or debian disable netgroup caching until Red Hat shakes out all the bugs. Alternatively someone from Debian could help upstream. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
On Fri, Aug 2, 2013 at 7:45 PM, Hal BugsBuster wrote: > I cannot fully explain what I am doing exactly but > I am working on soft real-time avionic problems and the use of libm2-17 > is ... IMPOSSIBLE since it multiplies by two the duration of all our > computations... I'm sorry to hear that, please feel free to volunteer your time to help upstream glibc or debian ensure that issues like this get fixed and tested quickly. Alternatively you can get involved to voice your opposition to changes to fix correctness over performances. > Do you mean that all these catastrophic overheads are no longer > existing in libm-2.18 ? The overhead depends on the rounding mode you are in. If you are using the default rounding mode and are on x86 or x86-64, then the overhead is significantly reduced in 2.18 (almost back to the original performance). > In this case, please do not read the following sentences, > this is really a good result for "me". You don't really want all of 2.18, just the fix to bring performance back for certain libm functions. > Otherwise - I cannot believe it - but I should mention that > I am just using mathematic libraries as a "beginner" and I do not want to > enter in sophisticated modes of the libm > (no time/money for this) as well as the worldwide company for which > I am working... and I fully disagree on the fact that > "the tradeoff is justified" this is absolutely not true in my case and I do > not > use specific rounding modes, just the default options of the libm > and gcc... Don't upgrade to 2.17 then. Wait for the bug to get fixed. > Fortunately, till now same results are obtained via libm-2.13 and > libm-2.17... > but how can I explain/justify that it needs almost twice as much time? > It is just IMPOSSIBLE/INCREDIBLE! The same results for some small finite set of inputs you tested? Upstream needs to make sure it returns correct results for the entire set of inputs in all modes. In this particular case we chose returning a correct answer over returning an incorrect answer (albeit quickly). This fixed a serious and real problem that other users were facing. Once we had that problem fixed we then proceeded to fix the performance and to try and restore it to original levels without returning incorrect answers. > I think that this will have a *SERIOUS* negative impact on the trust in > linux in its ability > to stay competitive/efficient in this kind of computations... I disagree. Linux has nothing to do with this. This is all in the GNU C Library. You rely on your distribution to be aware of issues like this and to ensure that their glibc is updated in a timely fashion. Each distribution does what they do for their users. There are other distributions which have this defect already fixed. You are free to use whatever distribution you want. I bet Debian will have this fixed quickly, but you need to talk them to get it fixed. I'm an upstream glibc maintainer who reads this list in order to provide quick feedback about glibc issues. > Am I really the only one facing these ugly counterperformances of libm? No. Lots of other people have reported this problem. > So, sorry again if I misunderstood something, > but I also need to automatize the installation of the mentioned > program on several computers without using complicated tricks as backports > and so on... So,what is the best and efficient way to proceed ? That is for you to judge with the help of those who assist you in your system installation and configuration. I'm not here to help in that capacity. > Keep libm-2.13 as long as possible > or avoid any further trigonometric computation on Linux > (and start using an FPGA -for instance - to be more efficient with future > versions of libm)? That is up to you to decide. Given that you have stated you have limited resources I would simply wait for the bug to be fixed. > To be "as constructive as possible", > is there a simple/concrete way to use the right rounding mode (WITHOUT > MODIFYING > THE FINAL RESULTS) in gcc with libm-2.18 or libm-2-17 with NO overhead? > Otherwise, this is - in my opinion - really catastrophic for > [Debian_]Linux... No. You need to get glibc updated. And it's "Debian GNU/Linux", but it also impacts any Debian derivative that uses glibc e.g. Debian GNU/kFreeBSD. > Sorry for my comments, as I said I am NOT a specialist in libm nor > trigonometric "tricks" > but I cannot hide the fact that I am really disappointed by > this answer if there is no simple solution based on libm-2.17 or > libm-2.18... Upstream glibc is working very hard on performance microbenchmarks to use to ensure that core functional changes do not regress performance between releases. The math library is the first target for this microbenchmark framework. It is the first framework of it's kind in glibc, there has never been one in the past before. It is our hope that with the framework in place we can better determine the final performance impact that certain changes have
Bug#718577: libc6: Libc6/libm-2.17 almost two times slower than 2.13 in trigonometric calculations
On Fri, Aug 2, 2013 at 12:10 PM, bugsbuster wrote: >* What led up to the situation? Upstream glibc fixed a number of correctness issues in non-default rounding modes. These correctness issues had a performance impact which has only just been fixed in 2.18. I suggest Debian backport Siddhesh Poyarekar's work to fix this: ~~~ commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar Date: Wed Jun 12 10:36:48 2013 +0530 Set/restore rounding mode only when needed The most common use case of math functions is with default rounding mode, i.e. rounding to nearest. Setting and restoring rounding mode is an unnecessary overhead for this, so I've added support for a context, which does the set/restore only if the FP status needs a change. The code is written such that only x86 uses these. Other architectures should be unaffected by it, but would definitely benefit if the set/restore has as much overhead relative to the rest of the code, as the x86 bits do. Here's a summary of the performance improvement due to these improvements; I've only mentioned functions that use the set/restore and have benchmark inputs for x86_64: Before: cos(): ITERS:4.69335e+08: TOTAL:28884.6Mcy, MAX:4080.28cy, MIN:57.562cy, 16248.6 calls/Mcy exp(): ITERS:4.47604e+08: TOTAL:28796.2Mcy, MAX:207.721cy, MIN:62.385cy, 15543.9 calls/Mcy pow(): ITERS:1.63485e+08: TOTAL:28879.9Mcy, MAX:362.255cy, MIN:172.469cy, 5660.86 calls/Mcy sin(): ITERS:3.89578e+08: TOTAL:28900Mcy, MAX:704.859cy, MIN:47.583cy, 13480.2 calls/Mcy tan(): ITERS:7.0971e+07: TOTAL:28902.2Mcy, MAX:1357.79cy, MIN:388.58cy, 2455.55 calls/Mcy After: cos(): ITERS:6.0014e+08: TOTAL:28875.9Mcy, MAX:364.283cy, MIN:45.716cy, 20783.4 calls/Mcy exp(): ITERS:5.48578e+08: TOTAL:28764.9Mcy, MAX:191.617cy, MIN:51.011cy, 19071.1 calls/Mcy pow(): ITERS:1.70013e+08: TOTAL:28873.6Mcy, MAX:689.522cy, MIN:163.989cy, 5888.18 calls/Mcy sin(): ITERS:4.64079e+08: TOTAL:28891.5Mcy, MAX:6959.3cy, MIN:36.189cy, 16062.8 calls/Mcy So the improvements are: cos: 27.9089% exp: 22.6919% pow: 4.01564% sin: 19.1585% tan: 1.96086% The downside of the change is that it will have an adverse performance impact on non-default rounding modes, but I think the tradeoff is justified. ~~~ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714219: #714219 - libc6: crypt(3) returns NULL… told you so
On 07/18/2013 06:11 AM, Thorsten Glaser wrote: > Told you so… > > -- Forwarded message -- > Subject: apt-listchanges: changelogs for tglase.lan.tarent.de > > cyrus-sasl2 (2.1.25.dfsg1-14) unstable; urgency=low > > * CVE-2013-4122: Handle NULL returns from glibc 2.17+ crypt() > (Closes: #716835) > I'm happy to see applications being fixed to follow the documented standard. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714219: [Debian #714219] libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
On Tue, Jul 2, 2013 at 12:52 PM, Alexandre Oliva wrote: > At this point, I'd rather we took the opportunity to fix code that makes > unsafe assumptions about the behavior of crypt than push the problem on > for users to figure out when a glibc upgrade causes passwords to fail to > be recognized because the salt suggests the use of a different, > newly-recognized encryption algorithm. Fully agreed. > This is my current rationale for the current implementation, after two > rounds of discussion on its merits. I must admit I'm not comfortable > with the change that was made to out-of-alphabet DES salt, but ATM I'm > even less comfortable with the alternatives. I didn't always favor the > current situation, and that might change again depending on arguments I > get. But then, I don't have the final word on any of this ;-) > > So, if the rationale above doesn't make you as (un)happy as I am about > the current state of crypt in glibc, please bring forth your > counterarguments and let's see if we can all come to a sensible > agreement. Exactly. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#714219: libc6: crypt(3) returns NULL with EINVAL instead of falling back to DES, breaking GNU software
>From the 2.17 NEWS:
* The `crypt' function now fails if passed salt bytes that violate the
specification for those values. On Linux, the `crypt' function will
consult /proc/sys/crypto/fips_enabled to determine if "FIPS mode" is
enabled, and fail on encrypted strings using the MD5 or DES algorithm
when the mode is enabled.
> tst(" ", "%qb?,db=yu'd,0h0%db:3?,c?=,d dZ,?=I:yZZ30 eZy=a%0 d");
This string contains invalid salt crypt character.
POSIX says:
~~~
Otherwise, it shall return a null pointer and set errno to indicate the error.
~~~
Therefore returning null and setting errno is entirely appropriate.
All conforming applications should check for NULL.
Conforming implementations may return additional errors to those
listed by POSIX
It is only a problem if you don't return the listed errno for the same error.
> if (strcmp(p->pw_passwd, crypt(oldpasswd, p->pw_passwd)) == 0) {
Examples are non-normative. They are simply informative and may assume things
like always using valid salt characters.
> If this is an error at all… on wheezy it was none, and BSD agrees:
It is not an error. You can't use invalid salt strings.
> Please fix this to at least never return NULL with something
> else than an ENOSYS condition (crypt(3) not implemented at all),
> because this *will* break unrelated software.
That will not get accepted upstream.
Please fix your application to conform with POSIX.
You must check the result and act appropriately when you see a NULL return
including cleaning the input to contain only valid salt characters.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711913: libc6: ld.so falsely claims the vDSO comes from a file
On Mon, Jun 10, 2013 at 4:22 PM, Samuel Bronson wrote: > With Drepper gone, upstream is now interested in a fix, but say they > aren't likely to get to it anytime soon themselves, and seem to want > something at least slightly more involved than what Redhat has. > > (In particular, they seem to want such a patch to fix LD_DEBUG=scopes to > work nicely *without* re-activating the "lying" behaviour.) That's right. The act of using a false file name for the vDSO during debug is a temporary solution. We have the ability to support a vDSO with a name but no file name, one just have to fix up all access to the file name to understand there might not be one. We are always looking for more volunteers :-) Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672934: tagging 672934
On 9/26/2012 6:07 AM, Andreas Henriksson wrote: > Hello again! > > On Tue, Sep 25, 2012 at 03:07:54PM +0200, Aurelien Jarno wrote: > [...] >>> Anything someone can help out with? >> >> You can build it and try it. > > Would like to report that I'm getting test failures > > First build these tests failed: > > Encountered regressions that don't match expected failures: > tst-cputimer1.out, Error 1 > tst-eintr1.out, Error 1 > > The cputimer1 test said timer returned too soon. This is a known kernel bug on x86, along with rt/tst-cpuclock2. > I did two more (clean) builds and then only the eintr1 test failed. > > tst-eintr1.out said: This is *also* a kernel bug and we're working upstream to fix the testcase to be a bit more stable. http://sourceware.org/ml/libc-alpha/2012-09/msg00538.html Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592751: Broken on hppa; programs abort with malloc assertion failure
On Thu, Aug 19, 2010 at 1:56 PM, Yavor Doganov wrote:
> Do you find anything disturbing in this approach, in particular:
Yes, you don't take into account the alignment requirement of the structure.
> --- Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28611)
> +++ Headers/Additions/GNUstepBase/GSConfig.h.in (revision 28613)
> @@ -203,5 +203,18 @@
> #define GSNativeChar char
> #endif
>
> +/*
> + * Types used to avoid exposing pthread header in NSLock.h
> + * NB. These types should *never* be used except to provide enough space
> + * in a class layout for the type of data actually used by the pthread
> + * implementation of the current platform.
> + */
> +typedef struct {
> + uint8_t dum...@gs_sizeof_cond_t@];
> +} gs_cond_t;
> +typedef struct {
> + uint8_t dum...@gs_sizeof_mutex_t@];
> +} gs_mutex_t;
> +
>
> @GS_SIZEOF_COND_T@ and @GS_SIZEOF_MUTEX_T@ should be both 48 on hppa.
> (Mehdi/Dann, can you double check that by grepping GSConfig.h?)
>
> Apparently this trick works on all platforms (including hppa on Lenny,
> where I've run complex programs in my desire to reproduce).
The pthread_mutex_t and pthread_cond_t on hppa are __attribute__
((aligned(16))), which means if you embedded them into another
structure they need to be padded out to that alignment. The dummy
structure you use here doesn't match the alignment and may break ABI.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592751: Broken on hppa; programs abort with malloc assertion failure
On Thu, Aug 19, 2010 at 12:38 PM, dann frazier wrote: >> There *was* a vfork bug that was just fixed in glibc that could cause >> problems. > > Are you referring to this one? > > * Add patches/hppa/cvs-vfork.diff to fix stack frame creating during > vfork in multithreaded environments. > > fwiw, we are seeing this issue on the latest eglibc, which contains > this change. That was the bug. However, the earlier comments in this bug indicate it might not be vfork related. The first step is to capture this with gdb and get a backtrace, just like you would with any other bug. There is nothing difficult about this, just time consuming. Once we have a backtrace, either via a core dump, or attached gdb, then we can talk about the likely cause. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592751: Broken on hppa; programs abort with malloc assertion failure
On Thu, Aug 19, 2010 at 11:00 AM, Mehdi Dogguy wrote: > On 19/08/2010 16:29, Yavor Doganov wrote: >> В 16:15 +0200 на 19.08.2010 (чт), Mehdi Dogguy написа: >>> On 19/08/2010 15:45, Yavor Doganov wrote: Thanks, informing upstream. Can you narrow it down a bit more? >>> >>> I narrowed it down to r28600:r28625. >> > > It's even r28610:r28615. I'm the person to ask about hppa and NPTL (I wrote the code). There *was* a vfork bug that was just fixed in glibc that could cause problems. Does this code use vfork? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#588391: gcc-4.4: please automatically use -ffunction-sections when necessary with -fPIC
On Fri, Aug 6, 2010 at 11:03 AM, Matthias Klose wrote: > On 06.08.2010 00:58, brian m. carlson wrote: >> >> On Thu, Aug 05, 2010 at 10:59:18PM +0200, Matthias Klose wrote: >>> >>> On 08.07.2010 01:42, brian m. carlson wrote: Package: gcc-4.4 Version: 4.4.4-6 Severity: wishlist Because the ELF ABI for hppa requires relative jumps which are limited to 17 bits[0], programs frequently require the use of -ffunction-sections. It would be preferable if (on hppa or otherwise) -ffunction-sections were implied by -fPIC when otherwise gcc would generate text sections that are too large. After all, there's really no reason to generate .o files that are, for all practical purposes, useless. It would also make numerous package maintainers and hppa porters very happy, I suspect. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999#15 >>> >>> as this specific example shows, -ffunction-sections isn't enough, >>> but -mlong-calls is needed. >> >> In that particular instance -mlong-calls is needed, but in the general >> case it appears not to be, judging from the numerous cases where only >> -ffunction-sections (and not -mlong-calls) is in use already in the >> archive. For example, #160538. >> >> My wishlist request still stands. > > waiting for feedback form the HPPA porters. To make this automatic would require a lot more intelligence in the linker. My suggestion is to change the specs such that -fPIC implies -ffunction-sections. Dave, any comment? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#587545: FTBFS [hppa]: java.lang.OutOfMemoryError: Cannot create additional threads
On Tue, Jun 29, 2010 at 1:03 PM, dann frazier wrote: > [junit] 0 threads=10 idle=0 > [junit] 100 threads=6 idle=6 > [junit] 200 threads=3 idle=3 > [junit] 300 threads=2 idle=2 > [junit] 400 threads=2 idle=2 > [junit] 500 threads=2 idle=2 > [junit] 13458 [main] WARN org.mortbay.log - failed > org.mortbay.thread.queuedthreadp...@6d6c7130: java.lang.OutOfMemoryError: > Cannot create additional threads How many threads did it actually try to create? Given our 8MB stack size, and alignment requirements, you can't create more than ~368 threads on hppa (glibc/nptl). Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575263: Please add support for hppa
On Sat, Apr 17, 2010 at 8:18 AM, Matthias Klose wrote: > I attached a build log for an hppa 6b18-1.8-1 build attempt to the bug > report; I don't know of anybody working on this. > > See > http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-January/002529.html For avoidance of doubt. I am not working on this right now. I'm working on glibc regressions that need to be resolved before the end of the month. cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#575351: [HPPA] This is not the bug of GCC but glibc
On Mon, Mar 29, 2010 at 5:28 AM, NIIBE Yutaka wrote: > I am looking the file: > eglibc-2.10.2/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h > > It doesn't have any cfi directives. I think that it is the cause > of this problem. > > When adding cfi directives, it would be good to add nocancel version > of functions. I have now added cfi directives to both sysdep.h and sysdep-cancel.h for all assembly wrappers used by glibc. In addition I have also provided a nocancel version in sysdep-cancel.h. Once I finish testing the cfi directives I'll push this into libc-ports and debian can pull the changeset. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#572384: opal_3.6.6~dfsg-4/hppa FTBFS: undefined reference to `non-virtual thunk to PVXMLSession::Trigger()'
On Thu, Mar 18, 2010 at 7:47 AM, Adam D. Barratt wrote: >>> ../../lib_linux_hppa/libopal.so: undefined reference to `non-virtual >>> thunk to PVXMLSession::Trigger()' What does this error mean? > [...] >> The PVXMLSession::Trigger() functions which give errors are found in >> ptlib, but in both cases the same ptlib package was used, cf. >> https://buildd.debian.org/fetch.cgi?pkg=opal;ver=3.6.6~dfsg-3;arch=hppa;stamp=1255622898 >> and >> https://buildd.debian.org/fetch.cgi?pkg=opal;ver=3.6.6~dfsg-4;arch=hppa;stamp=1268343033 >> >> Unpacking libpt2.6.5 (from .../libpt2.6.5_2.6.5-1_hppa.deb) ... >> and >> Unpacking libpt2.6.5 (from .../libpt2.6.5_2.6.5-1_hppa.deb) ... You could try running with LD_DEBUG=1 which will generate a trace of all the dynamic loader actions for the working and non-working cases, and compare how the symbols are being resolved? This is useful for example if your dynamic libraries are being built incorrectly by libtool, which has been the cause of other failures I've seen in the past. >> So I would rather expect a failure due to the compiler (4.3->4.4), which >> is different: >> Toolchain package versions: libc6-dev_2.9-26 linux-libc-dev_2.6.30-8 >> g++-4.3_4.3.4-5 gcc-4.3_4.3.4-5 binutils_2.19.91.20090927-1 >> libstdc++6_4.4.1-6 libstdc++6-4.3-dev_4.3.4-5 >> and >> Toolchain package versions: libc6-dev_2.10.2-6 dpkg-dev_1.15.5.6 >> linux-libc-dev_2.6.32-9 g++-4.4_4.4.3-3 gcc-4.4_4.4.3-3 >> binutils_2.20.1-2 libstdc++6_4.4.3-3 libstdc++6-4.4-dev_4.4.3-3 Yes, 4.3 is different from 4.4, I have CC'd John David Anglin our GCC expert to see if he is aware of any known issues. >> Are you aware of such a problem on hppa architecture (the other >> architectures build well, and there is no #define ...HPPA... in .cpp >> files)? Maybe this is linked to >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558999 ? No, I would expect the linker to detect this problem (as it does in the case of the bug example). > I'm not aware of any issues myself. I've CCed the HPPA porter list to see > if they have any ideas. I'm not aware of any issues associated with the compiler. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error
On Fri, Feb 26, 2010 at 3:14 AM, Petr Salinger wrote: > My point is a different one, see in #570889. > > 14997 gij-4.4 CALL open(0x8e59e58,O_RDONLY|O_LARGEFILE,0) > 14997 gij-4.4 NAMI ".../defaults.properties" > 14997 gij-4.4 RET open 10/0xa > 14997 gij-4.4 CALL fstat(0xa,0xbfbf29ec) > 14997 gij-4.4 STRU size=1701 > 14997 gij-4.4 RET fstat 0 > 14997 gij-4.4 CALL mmap(0,0x2000,PROT_READ,MAP_PRIVATE,0xa,0,0) > 14997 gij-4.4 RET mmap 712716288/0x2a7b3000 > 14997 gij-4.4 PSIG SIGBUS SIG_DFL > > The ant/gij-4.4 mmaps 8192 bytes from file of size 1701 > on architecture with pagesize 4096. If ant mmap's a file that has only 1701 bytes, on an architecture with page size of 4906, then any access beyond the first page will cause a SIGBUS. POSIX mmap says: * The system will zero-fill a partial page at the end of an object. Thus bytes 1701->4095 are zero-filled. * Access to any whole page past the end of an object shall result in SIGBUS. Thus access to bytes 4096->8192 will result in a SIGBUS. If ant is accessing whole pages beyond the length of the object (not the length of the required mmap) then this is a bug. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error
On Thu, Feb 25, 2010 at 7:22 PM, Petr Salinger wrote: >> On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger >> wrote: >>> >>> The file, which have to be copied, have size 1701, >>> but two pages (2*4096) are mmaped. It is allowed on both >>> Linux and FreeBSD. >>> When the 2nd page of that file would be accessed, it would >>> generate SIGBUS. >>> >>> The question is of course whether it really happens and why ? > >> File descriptor 0 is standard input and you can't mmap that. >> You should also check the return of mmap. >> Could you please provide a new test case? > > Please really try to run the example code, > for me (pagesize 4096) it gives: > > 0x800636000 32 > 0x800636000 0 > Bus error > > The example code just illustrates what might happen in > failure of ant. The affected architectures directly in > ant build have been only kfreebsd-* and hppa. > > Now it looks like wider problem - #571532, #571542, #571397. Does ant actually try to mmap stdin? That's a bug in ant. POSIX says you may only mmap a file, shared memory object, or typed memory object. The stdin file descriptor is neither of those things therefore you can't mmap stdin. One might argue the bug is that the Linux kernel allows the mmap to succeed. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#570889: #570889 ant: FTBFS on kfreebsd-* and hppa: Bus error
On Thu, Feb 25, 2010 at 9:23 AM, Petr Salinger wrote:
> The file, which have to be copied, have size 1701,
> but two pages (2*4096) are mmaped. It is allowed on both
> Linux and FreeBSD.
> When the 2nd page of that file would be accessed, it would
> generate SIGBUS.
>
> The question is of course whether it really happens and why ?
> Petr
>
> gcc tst.c -o tst
> tst < tst.c
>
> ---
> #include
> #include
>
> int main()
> {
>
> char *p = mmap(0, 8192,PROT_READ,MAP_PRIVATE,0,0);
File descriptor 0 is standard input and you can't mmap that.
You should also check the return of mmap.
Could you please provide a new test case?
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559085: Max number of threads on HPPA
On Tue, Jan 19, 2010 at 2:43 AM, dann frazier wrote: > On Tue, Jan 19, 2010 at 12:57:21AM +0100, Frans Pop wrote: >> Carlos O'Donell wrote: >> > Can you please ptrace the failing test with -ff and get me the log? >> >> I've built odin in a 'pbuilder login' chroot using the following >> instructions from Michael (from private mail). >> >> On Monday 18 January 2010, Michael Hanke wrote: >> > Cool, thanks. Here is how it should work: >> > >> > $ debcheckout odin >> >> I used 'apt-get source' as I wanted to have the current unstable version >> (1.8.1-1). >> >> > $ sudo apt-get build-dep odin >> > $ cd odin/ >> > $ DEB_BUILD_OPTIONS=nocheck debuild -uc -us -i >> > >> > AFAIK, there is no way to run specific tests individually, but the full >> > testsuite can be started like this: >> > >> > neurodeb...@lego:~/tmp/odin$ ./cmdline-utils/odintestsuite >> >> There's just one problem: I cannot reproduce the error... >> >> # ./cmdline-utils/odintestsuite > > I tried this on paer and I also couldn't reproduce by running the > command standalone, but I can reproduce when executed as part of 'make > check'. > > I can collect information from this if desired - though, I'm not > familiar with the ptrace command (did you mean strace?) Sorry, Dann, yes I did mean strace. I've just been staring at some ptrace kernel code and wrote the wrong thing :-) Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559085: [Pkg-exppsy-maintainers] Bug#559085: Max number of threads on HPPA
On Sun, Jan 17, 2010 at 1:09 PM, Michael Hanke wrote: > On Sun, Jan 17, 2010 at 01:02:51PM -0500, Michael Hanke wrote: >> On Sun, Jan 17, 2010 at 10:49:43AM -0500, Carlos O'Donell wrote: >> > On Sun, Jan 17, 2010 at 10:31 AM, Frans Pop wrote: >> > > Michael Hanke wrote: >> > >> I maintain ODIN, a simulator for magnetic resonance imaging sequences. I >> > >> utilizes threads for its simulations and its test suite tries to create >> > >> 256 thread. This test suite runs during package build-time -- and always >> > >> fails on HPPA, and just HPPA, e.g. >> > >> > Can you please ptrace the failing test with -ff and get me the log? >> >> Just to clarify: I want to me to ptrace the test on a non-hppa machine? > ^ > > s/I/You -- of course. No. I would like a ptrace '-ff' of the test on an hppa machine. If you need an hppa machine please use paer, or ask on debian-hppa for an account on a users machine (several people help out with this). Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559085: Max number of threads on HPPA
On Sun, Jan 17, 2010 at 10:31 AM, Frans Pop wrote: > Michael Hanke wrote: >> I maintain ODIN, a simulator for magnetic resonance imaging sequences. I >> utilizes threads for its simulations and its test suite tries to create >> 256 thread. This test suite runs during package build-time -- and always >> fails on HPPA, and just HPPA, e.g. Can you please ptrace the failing test with -ff and get me the log? > Sounds similar to http://bugs.debian.org/557982. That BR is closed because > it was worked around, but I think the underlying issue is unresolved. > > Carlos? It does sound similar to BR 557982, the workaround in that issue was to ignore the failure, effectively marking this test as "Expected failure" for the hppa target. The maximum thread count with default stacks is ~381 threads, but if each thread has a lot of thread local data then this number goes down. Please understand that we are still stress testing the threading on hppa, and not all of the problems have been worked out. Thank you for your patience. >> I have no access to a HPPA machine and hence cannot look at >> /proc/sys/kernel/threads-max without uploading a new package version. > > On my box: > > $ uname -r > 2.6.32-trunk-parisc64-smp > $ cat /proc/sys/kernel/threads-max > 15984 This is the maximum, but it is only achievable if you reduce the default 8MB stack size. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561203: Re: Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
On Sun, Dec 27, 2009 at 9:47 AM, Luk Claes wrote: > What's the status of this bug? It's holding the KDE transition which is > blocking the Xorg and python transitions... I'm working on this bug. The current status is "under investigation." I don't have a good idea of what is going on or why it's crashing. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#561203: FTBFS [hppa] - pthread_create() (QThread) + fork() = crash
On Tue, Dec 22, 2009 at 2:54 PM, Modestas Vainius wrote: > when investigating this issue further, I determined that fork() following > pthread_create() sometimes makes the application crash. In order to reproduce, > build attached minifail.cpp with: > > $ g++ -I/usr/include/qt4 -lQtCore minifail.cpp -o minifail -O0 -g Thank you for the test case. > This means that thread 2 was not started at all and hung at clone(). > Relevant QThread code at > http://qt.gitorious.org/qt/qt/blobs/4.5/src/corelib/thread/qthread_unix.cpp I don't believe that it would be stuck at the store instruction which is pointed to by the PC (iaoqh). However, I do believe that something is wrong and I am going to investigate the kde4libs failure tonight. > I strongly believe that if you fix the first problem, the 2nd one will > disappear too as their origin is the same. Both tests work just fine on amd64. > > Contrary to what I said previously, the bug is reproducible under strace -f, > but you have to wait much longer (up to 1th run). > > ii libc6 2.10.2-2 GNU C Library: > Shared libraries Thanks. I'll look into this tonight. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558980: access to hppa machine to work on Bug#558980
On Mon, Dec 14, 2009 at 7:46 AM, Stephen Leake wrote: >> If you see "transferring control:" then the dynamic loader has just >> handed off control the real program, and any fault after that is >> possibly related to the real program. > > That is there, although there are more symbols looked up after it. This is good news, it means the dynamic loader handed control to the program. > So I will leave hppa in the arch list, but remove the stack check > option. Would it be possible for you to keep open a low severity bug indicating that this needs to be fixed? Remember to tag the bug hppa, so that I can track it on our ports to-do list e.g. http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;which=tag&data=hppa&archive=no We are working through the tagged bugs to try make progress. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#559406: SIGFPE trapping on HPPA (was: Yorick FTBFS: DM needs access to HPPA machine)
On Mon, Dec 14, 2009 at 9:32 AM, Thibaut Paumard wrote:
> Under some circumstances (when and integer SIGFPE has been raised
> previously), I have been able to have my handler output a short message, but
> then it loops (this short message is repeated indefinitely). Calling
> feclearexcepts() before outputting this message did not help: when
> attempting a floating-point division by zero, either yorick dies or the
> handler loops. The first three lines of the handler on this test case are:
> feclearexcept(FE_ALL_EXCEPT);
> printf("in u_sigfpe\n");
> fflush(stdout);
>
> The handler is setup using signal(2):
> signal(SIGFPE, &u_sigfpe)
>
> HPPA is the only architecture so far which exhibits this behaviour.
>
> Does anyone has an idea of what I could do to fix this? Is there something
> specific in the way HPPA handles SIGFPE trapping? Why is it different
> between integer SIGFPE and floating SIGFPE?
Could you please provide a small test case and describe the expected behaviour?
I'll look at the test case and see if there is any corner cases
missing from the glibc floating point exception handling code.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#558905: Kernel bug.
IMO this FTBS is a kernel vfork bug. The return register in the parent is being corrupted. Using the emacs23 source I was able to produce a trimmed down test case for the failing vfork. I have reported this to our kernel developers here: http://article.gmane.org/gmane.linux.ports.parisc/2403 Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557982: Should be fixed now.
On Tue, Dec 1, 2009 at 9:26 AM, Daniel Burrows wrote: >> debian-hppa, any clue why cwidget would get an error when trying to >> create 50 threads, and how to fix this? > > According to the build logs for 0.5.16-2, it successfully creates > 37 new threads, failing on the 38th. More annoyingly, it looks like > sysconf is not reporting the existence of a limit on the number of > threads the test can create; both tests are trying to create their > default number of threads (the number of threads to create would have > been lowered to the limit had sysconf indicated that there was a > limit -- I thought maybe I had an off-by-one error in how I was > computing the limit, but apparently that's not the case). > > Anyway, the build looks like it succeeded now that the failed > pthread_create is ignored. On hppa you get at *most* ~381 threads with the default 8MB stacks, and the required shared libraries loaded. Starting 50 threads should not be a problem. For the record I can't reproduce the cwidget failure locally, when I run the test it correctly creates 50 threads, and passes the test. I will assume this is a kernel/glibc issue and continue to work on making both more reliable in the future. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557982: Should be fixed now.
On Mon, Nov 30, 2009 at 4:58 PM, Julien Cristau wrote: > reopen 557982 > kthxbye > > On Mon, Nov 30, 2009 at 12:28:31 -0800, Daniel Burrows wrote: > >> With any luck, this is fixed in 0.5.16-1 in unstable. I addressed the >> problem by having the tests query for the system limit on the number of >> threads they could create, then stop at that many. Hopefully that >> should get them to pass on hppa, but obviously I can't test that myself, >> so please let me know if it fails again. >> > Looks like it failed again. > https://buildd.debian.org/fetch.cgi?pkg=cwidget;ver=0.5.16-1;arch=hppa;stamp=1259584731 > > debian-hppa, any clue why cwidget would get an error when trying to > create 50 threads, and how to fix this? Without more analysis I can't comment on what might be the cause. I recently ran the LTP nptl01 test and it ran without a problem. This failure might be a kernel bug, or a glibc bug, or both. We've done the right thing though, this issue is tagged with hppa and it shows up on our list here: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-h...@lists.debian.org;which=tag&data=hppa&archive=no I will add it to my list of failures to review. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#557984: Use of -m64 is invalid on hppa-linux-gnu.
It is not valid to use -m64 on hppa. We do not have a multi-arch compiler, and we only support the 32-bit userspace. Has this package ever built for hppa? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#389306: Atomic builtins and atomic functions in glibc are now implemented.
The hppa-linux-gnu target now has atomic builtins in gcc, and atomic.h functions exported by glibc. What else is needed by openmpi? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, Nov 23, 2009 at 8:48 AM, Aurelien Jarno wrote: >> Next steps: >> (1) Wait for testsuite results to finish completely. Verify nothing >> has regressed. No regressions. >> (2) Remove changes to gcc package debian/rules2 and re-run validation. Some regressions caused by enabling cloog/ppl, however these regressions do not break the libstdc++6 package in any critical way. Re-running the test case by hand now works, and the C++ class has the correct offsets. >> (3) In parallel provide new patch to debian-glibc to fix alignment >> issues with pthread types. Done. >> (4) Ask debian-glibc team to run a build and look for testsuite regressions. Done. >> If the test results for (2) and (4) are clean, then I will give the >> green light for a new glibc to be uploaded. This will fix the >> libstdc++6 issues. The test results for (2) and (4) are clean enough for a release given my QA. > I guess there is a fifth step need: > (5) rebuild gcc-4.4 against the fixed glibc. Aurelian has uploaded a new glibc with the fix and informs me that gcc is currently rebuilding. Once I conform that the newly built gcc is OK, we can close this issue and start building packages again. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Mon, Nov 23, 2009 at 5:22 AM, Aurelien Jarno wrote: > Carlos O'Donell a écrit : >> On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin >> wrote: >>>> While I set out the glibc types exactly as before (binary compatible), >>>> the alignment restrictions were changed subtly. >>> Excellent debugging! >> >> I have adjusted the glibc lock structure alignments to try and match >> more accurately the original alignment restrictions. >> >> I have built a glibc with the new headers, and installed that into my >> test system. >> >> I'm now rebuilding libstdc++6 against the new headers to determine if >> this fixes the problem. >> >> I will have results by tomorrow. >> > > Thanks a lot for the investigation, I really hope this will work. It worked. I now see 0xb0 as the object offset, which gives a compatible object layout for the libstdc++ iostream classes. (gdb) x/16x $ret0 - 0xc 0x409a6f38 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>: 0x00b0 0x 0x409a72f0 0x401b2b96 0x409a6f48 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>: 0x401b2b9e 0xff50 0xff50 0x409a72f0 0x409a6f58 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>: 0x401b2ba6 0x401b2bae 0x 0x409a6ff4 0x409a6f68 <_ZTVSt13basic_filebufIcSt11char_traitsIcEE+8>: 0x401b2e6e 0x401b2e76 0x401b2e7e 0x401b2e86 I can successfully run apt-get with the new libstdc++6 that I just built. The testsuite result is cleaner: ~~~ FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test === libstdc++ Summary === # of expected passes5880 # of unexpected failures2 # of expected failures 80 # of unsupported tests 331 ~~~ I am still building with ~~~ # Disable cloog/ppl and pch on hppa. ifneq (,$(findstring $(DEB_TARGET_ARCH), hppa)) CONFARGS += --without-ppl --without-cloog --disable-libstdcxx-pch endif ~~~ However, I don't think this made any difference. Next steps: (1) Wait for testsuite results to finish completely. Verify nothing has regressed. (2) Remove changes to gcc package debian/rules2 and re-run validation. (3) In parallel provide new patch to debian-glibc to fix alignment issues with pthread types. (4) Ask debian-glibc team to run a build and look for testsuite regressions. If the test results for (2) and (4) are clean, then I will give the green light for a new glibc to be uploaded. This will fix the libstdc++6 issues. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 5:05 PM, John David Anglin wrote: >> While I set out the glibc types exactly as before (binary compatible), >> the alignment restrictions were changed subtly. > > Excellent debugging! I have adjusted the glibc lock structure alignments to try and match more accurately the original alignment restrictions. I have built a glibc with the new headers, and installed that into my test system. I'm now rebuilding libstdc++6 against the new headers to determine if this fixes the problem. I will have results by tomorrow. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 2:51 PM, Carlos O'Donell wrote: > This happens because the original locale object was created at address > 0xbff01c20. However, when apt-get calls "std::basic_ios std::char_traits >::init" it passes in the address 0xbff01c18. > So we went from a constructor using this as 0xbff01c20, to eventually > passing this as 0xbff01c18 to a template. The pointer to the > std::ios_base object is now off by 8 bytes and this causes the crash. > > What happened here? Why does ReadConfigFile() think that the object is > in a different location? > > Any hints on how to track this down? The problem is here, we read 0xa8 here from libstdc++6: (gdb) x/16x $ret0 - 0xc 0x40437778 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si>: 0x00a8 0x 0x40437b30 0x401b2b96 0x40437788 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+16>: 0x401b2b9e 0xff58 0xff58 0x40437b30 0x40437798 <_ZTCSt14basic_ifstreamIcSt11char_traitsIcEE0_Si+32>: 0x401b2ba6 0x401b2bae 0x 0x40437834 Then we add this offset to the base location of the object on the stack and we compute 0xbff01c18, instead of computing 0xbff01c20 as we would expect. It looks like the layout of the object in libstdc++.so.6 has changed, my guess is that the changes I made to the locking types in glibc have caused the layout to be perturbed. While I set out the glibc types exactly as before (binary compatible), the alignment restrictions were changed subtly. I will go back immediately and review this. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sun, Nov 22, 2009 at 10:30 AM, John David Anglin wrote: >> > The problem appears to have gone away with head. I don't see it with >> > hpux. >> > >> >> Note that latest version of gcc 4.4 in Debian is built with >> --disable-libstdcxx-pch, but the segfault is this present :( > > Personally, I don't believe the segfault is related to the FAILs > seen in the libstdc++ testsuite. As you showed, there is an ABI > change in the library depending on libc version. Someone needs > to generate a backtrace so that we can get some idea what's happening. Running apt-get with the newly compiled libstdc++6 with --without-cloog/--without-ppl still cause the segfault. The glibc locale() function is causing this failure. The segfault happens when basic_ios is being initialized. The ios_base::_M_init() calls locale() to create a locale object and stores this into _M_ios_locale. The assignment is done through an operator= for the locale type, and this crashes. Starting program: /usr/bin/apt-get Program received signal SIGSEGV, Segmentation fault. std::locale::operator= (this=0xbff01c84, __other=...) at ../../../../src/libstdc++-v3/src/locale.cc:116 116 _M_impl->_M_remove_reference(); Current language: auto; currently c++ (gdb) bt #0 std::locale::operator= (this=0xbff01c84, __other=...) at ../../../../src/libstdc++-v3/src/locale.cc:116 #1 0x40390c10 in std::ios_base::_M_init (this=0xbff01fc8) at ../../../../src/libstdc++-v3/src/ios_locale.cc:43 #2 0x403a9858 in std::basic_ios >::init (this=0x4043e890, __sb=0xbff01fc8) at /home/carlos/fsrc/debian/gcc-4.4-4.4.2/build/hppa-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:128 #3 0x405c7eec in ReadConfigFile(Configuration&, std::string const&, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #4 0x405c79e8 in ReadConfigDir(Configuration&, std::string const&, bool, unsigned int) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #5 0x40606eac in pkgInitConfig(Configuration&) () from /usr/lib/libapt-pkg-libc6.9-6.so.4.8 #6 0x0001d8b8 in main () (gdb) This is the 14th call to std::locale::operator=, but the first call with an object that was created on the stack. The object *this a std::locale object, has an invalid _M_impl member, whose value should be a pointer to an implementation but instead it's a value of 0x8. This happens because the original locale object was created at address 0xbff01c20. However, when apt-get calls "std::basic_ios >::init" it passes in the address 0xbff01c18. So we went from a constructor using this as 0xbff01c20, to eventually passing this as 0xbff01c18 to a template. The pointer to the std::ios_base object is now off by 8 bytes and this causes the crash. What happened here? Why does ReadConfigFile() think that the object is in a different location? Any hints on how to track this down? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Sat, Nov 21, 2009 at 5:37 AM, Aurelien Jarno wrote: > > I confirm, it's what I see in the testsuite log: > > | 77 > | __signbitl > | version status: incompatible > | GLIBCXX_3.4 > | type: function > | status: added If __signbitl is the only failure in the abi_check, then that's easy to fix, the testsuite needs to be updated. With cloog/ppl disabled I still get 7 testsuite failures, so I'll have to dig into each failure tommorow and see what's wrong. ~~~ Running target unix FAIL: abi_check FAIL: 26_numerics/complex/13450.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/13450.cc compilation failed to produce executable FAIL: 26_numerics/complex/pow.cc (test for excess errors) UNRESOLVED: 26_numerics/complex/pow.cc compilation failed to produce executable XPASS: 26_numerics/headers/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 29_atomics/atomic_flag/clear/1.c execution test FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test FAIL: tr1/8_c_compatibility/complex/overloads_float.cc (test for excess errors) FAIL: tr1/8_c_compatibility/complex/overloads_int.cc (test for excess errors) UNRESOLVED: tr1/8_c_compatibility/complex/overloads_int.cc compilation failed to produce executable === libstdc++ Summary === # of expected passes5873 # of unexpected failures7 # of unexpected successes 1 # of expected failures 79 # of unresolved testcases 3 # of unsupported tests 331 ~~~ Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: libstdc++6: apt segfaults on hppa
On Fri, Nov 20, 2009 at 10:31 AM, Aurelien Jarno wrote: > Domenico Andreoli a écrit : >> On Thu, Nov 05, 2009 at 06:47:11PM +0100, Domenico Andreoli wrote: >>> On Thu, Nov 5, 2009 at 5:43 PM, Matthias Klose wrote: On 05.11.2009 14:30, Domenico Andreoli wrote: > frankly i do not know what to do next, besides trying to rebuild gcc-4.4 > 4.4.2-1 with latest eglibc to see if it is the culprit or rebuild against eglibc-2.9. could you do this as a test? >>> yes, build started >> >> the gcc 4.4.2-2 built with eglibc 2.9-25 has not the problem and current >> gcc 4.4.2-1 is built with eglibc 2.9-26 [0]. should i try building >> 4.4.2-1 with eglibc 2.10.1-5 or are we convinced it is NPTL? > > At least we are convinced it's eglibc 2.10.1, not 100% sure it is due to > NPTL. > > I have done some more tests, showing it's a bit more complicated than > that. apt-get from stable/testing/unstable: > - works with libstdc++6 built against eglibc 2.9 > - segfaults with libstdc++6 built against eglibc 2.10.1 > > Then I tried to rebuild apt against the "broken" libstdc++6. > Surprisingly this new apt-get: > - works with libstdc++6 built against eglibc 2.10.1 > - segfaults with libstdc++6 built against eglibc 2.9 > > So in short, it seems that using eglibc 2.10.1 to build libstdc++6 > triggers an ABI change on this library. I haven't investigated more for > now, I am not sure when I'll have time to do it. This is not surprising, Dave has already pointed out that the debian libstdc++6 testsuite run clearly has an ABI failure e.g. ~~~ FAIL: abi_check ~~~ I'm running a build with --without-cloog/--without-ppl to see if that corrects the testsuite failures. We need to stop allowing packages to build if the testsuite runs aren't clean. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#556653: FTBS on hppa
On Tue, Nov 17, 2009 at 8:05 AM, Francesco Paolo Lovergine wrote: > make[2]: Leaving directory > `/build/buildd-cmake_2.8.0-1-hppa-6PIkTw/cmake-2.8.0/Build/Bootstrap.cmk' > loading initial cache file > /build/buildd-cmake_2.8.0-1-hppa-6PIkTw/cmake-2.8.0/Build/Bootstrap.cmk/InitialCacheFlags.cmake > Segmentation fault > > Relevant buildd output: > https://buildd.debian.org/fetch.cgi?pkg=cmake;ver=2.8.0-1;arch=hppa;stamp=1258382304 I can reproduce this. It appears to be a miscompilation of cmake by g++. I will look into a workaround for you. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554574: Status?
What is the status of this bug? Is it up to the package maintainer to disable cloog/ppl for hppa and try the build again? Speaking professionally, CodeSourcery enables cloog/ppl for our toolchain products, but we do a lot of additional testing to verify everything is working properly. At the end of the day, without a way to fail the source only upload build when the FAIL list changes, this will continue to be a problem for source only upload architectures like hppa. This type of problem could happen to any architecture. We need stricter build failure controls. I would suggest that the debian gcc package maintain a known good FAIL/XFAIL list and fail the build if that doesn't match. When a build fail happens the porters (like myself) should be contacted immediately to determine the cause of the regressions and fix the problem. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Sun, Nov 8, 2009 at 2:47 PM, Carlos O'Donell wrote: > On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donell > wrote: >> Always the same crash for all the failures I've looked at. Hopefully >> this is something trivial that was missed. > > The current libc is missing my patches to fix pthread_attr_setstack() > and pthread_attr_getstack() for hppa. With this patches: http://www.parisc-linux.org/~carlos/local-stack-grows-up.diff I know see this for the libjava testsuite in gcc trunk. ~~~ === libjava Summary === # of expected passes2568 # of unexpected failures3 # of untested testcases 3 ~~~ I've already asked Aurelien to apply the above listed patch. There is a regression in glibc, tst-attr3 fails randomly under load, but it isn't related to this code. I will be tracking that down independently of this patch. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Tue, Nov 10, 2009 at 10:32 AM, Carlos O'Donell wrote: > On Mon, Nov 9, 2009 at 9:37 PM, Matthias Klose wrote: >> looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well; >> is this reproducible for you? > > What regressions are you seeing? > > I have a check-g++ running right now against glibc 2.10.1-0exp2. I'll > comment when this is done. === g++ Summary === # of expected passes21250 # of unexpected failures26 # of expected failures 157 # of unresolved testcases 14 # of unsupported tests 168 === libstdc++ Summary === # of expected passes6913 # of unexpected failures1 # of unexpected successes 1 # of expected failures 86 # of unsupported tests 97 I'm seeing this with gcc upstream trunk compiled against glibc-2.10.1-0exp2. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Mon, Nov 9, 2009 at 9:37 PM, Matthias Klose wrote: > looking at the gcc-4.4 g++/libstdc++ test results I see regressions as well; > is this reproducible for you? What regressions are you seeing? I have a check-g++ running right now against glibc 2.10.1-0exp2. I'll comment when this is done. Does the gcc package do something similar to glibc and fail the build of the testsuite results fail to match expected results? In such cases the debian-glibc team contacts the porters to help sort out why the testsuite had changed, thus avoiding an upload that breaks userspace. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Sun, Nov 8, 2009 at 1:42 PM, Carlos O'Donell wrote: > Always the same crash for all the failures I've looked at. Hopefully > this is something trivial that was missed. The current libc is missing my patches to fix pthread_attr_setstack() and pthread_attr_getstack() for hppa. HPPA is an architecture under which the stack grows up and the default implementation does not take that into account. The boehm-gc then uses the wrong stack values during garbase collection initialization and thus every gcj built application crashes. I will work with Aurelian on putting out a fixed libc, until then gcj will not work correctly. Sorry about the inconvenience. It appears that the glibc testsuite is self-consistent, and because both set and get functions are affected the glibc tests actually pass. I didn't notice this because I don't normally bootstrap java. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Mon, Nov 2, 2009 at 11:17 AM, Carlos O'Donell wrote: > On Mon, Nov 2, 2009 at 5:01 AM, Aurelien Jarno wrote: >> Hi HPPA porters, >> >> Could someone please have a look at this problem? It seems to be due to >> the NPTL switch. > > I'm already looking at the gcj breakage so I'll have a look at this. Thanks. ~~~ === libjava Summary === # of expected passes877 # of unexpected failures842 # of untested testcases 842 ~~~ The testsuite failures are all caused by a crash in the garbage collector. #0 GC_push_all_eager (bottom=, top=) at ../../../gcc-trunk/boehm-gc/mark.c:1468 #1 0x42ac7aec in GC_push_all_stacks () at ../../../gcc-trunk/boehm-gc/pthread_stop_world.c:307 #2 0x42ac0f14 in GC_push_roots (all=1, cold_gc_frame=0xbff01708 "C\222\254DB\253U\24") at ../../../gcc-trunk/boehm-gc/mark_rts.c:646 #3 0x42ac0188 in GC_mark_some (cold_gc_frame=0xbff01708 "C\222\254DB\253U\24") at ../../../gcc-trunk/boehm-gc/mark.c:326 #4 0x42ab58ec in GC_stopped_mark (stop_fu...@0x438c166e: 0x42ab5514 ) at ../../../gcc-trunk/boehm-gc/alloc.c:531 #5 0x42ab6094 in GC_try_to_collect_inner (stop_fu...@0x438c166e: 0x42ab5514 ) at ../../../gcc-trunk/boehm-gc/alloc.c:378 #6 0x42ac2214 in GC_init_inner () at ../../../gcc-trunk/boehm-gc/misc.c:789 #7 0x42ac2500 in GC_init () at ../../../gcc-trunk/boehm-gc/misc.c:493 #8 0x42abb3f4 in GC_init_gcj_malloc (mp_index=0, mp=0x40247a5e) at ../../../gcc-trunk/boehm-gc/gcj_mlc.c:60 #9 0x41d40c28 in _Jv_InitGC () at ../../../gcc-trunk/libjava/boehm.cc:537 #10 0x41d2cd58 in _Jv_RegisterNewClasses (classes=0x1242c) at ../../../gcc-trunk/libjava/java/lang/natClassLoader.cc:364 #11 0x00010c84 in _Jv_global_static_constructor () at emptystring.java:13 #12 0x00010eb4 in __do_global_ctors_aux () #13 0x00010598 in _init () #14 0x00010e00 in __libc_csu_init () #15 0x40a22ffc in __libc_start_main (ma...@0x126be: 0x126d0, argc=1, ubp_av=0xbff0102c, in...@0x1269e: 0x10dc8 <__libc_csu_init>, fi...@0x12676: 0x126d0, rtld_fi...@0x4024787e: 0x4023708c <_dl_fini>, stack_end=0xbff011c0) at libc-start.c:181 #16 0x00010650 in _start () (gdb) Always the same crash for all the failures I've looked at. Hopefully this is something trivial that was missed. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554218: perl: FTBFS on hppa: Thread creation failed
On Wed, Nov 4, 2009 at 2:45 AM, Niko Tyni wrote: > tag 554218 fixed-upstream > thanks > > On Tue, Nov 03, 2009 at 05:15:06PM -0400, Carlos O'Donell wrote: > >> This is a bug in the perl test case. >> >> The error number 11 is EAGAIN, which means it needs to retry the >> thread creation. > > Thanks! I should probably have done some more homework first myself, sorry > about that. I was thinking of signal 11 which led me to the wrong track. Thank you for contacting the debian-hppa porters. I'm glad this is resolved! Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#554218: perl: FTBFS on hppa: Thread creation failed
On Tue, Nov 3, 2009 at 3:36 PM, Niko Tyni wrote:
> Package: perl
> Version: 5.10.1-6
> Severity: serious
>
> perl/5.10.1-6 failed to build on paer, see
>
> https://buildd.debian.org/fetch.cgi?pkg=perl&arch=hppa&ver=5.10.1-6&stamp=1256782011&file=log&as=raw
>
> 5.10.1-5 built OK, and as there were no related source changes in -6,
> I assume the libc NPTL switch is the culprit.
>
> Cc'ing the debian-hppa list. Could somebody please look into this?
> I don't know if perl needs to be recompiled against libc6 2.10 first or
> if it shows up with the system perl too.
>
> It should be enough to just run 'cd ext/threads-shared && perl t/stress.t'
> but I don't quite have the heart to try it out on paer and its chroot
> still has libc6 2.9 anyway.
>
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> Thread creation failed: pthread_create returned 11 at
> ../ext/threads-shared/t/stress.t line 77.
> # Warning: 13 threads failed
> # Note: errno 12 = ENOMEM
> # Test failed: 37 threads timed out
> ext/threads-shared/t/stress...FAILED at test
> 1
This is a bug in the perl test case.
The error number 11 is EAGAIN, which means it needs to retry the
thread creation.
POSIX says:
~~~
[EAGAIN]
The system lacked the necessary resources to create another
thread, or the system-imposed limit on the total number of threads in
a process {PTHREAD_THREADS_MAX} would be exceeded.
~~~
There are several code paths during thread creation that may return
EAGAIN, and the testsuite should handle that.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#553722: almost all execution test in gcj-4.4 broken with eglibc-2.10.1-3 on hppa
On Mon, Nov 2, 2009 at 5:01 AM, Aurelien Jarno wrote: > Hi HPPA porters, > > Could someone please have a look at this problem? It seems to be due to > the NPTL switch. I'm already looking at the gcj breakage so I'll have a look at this. Thanks. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546619: upcoming 4.5.19 release works on hppa
Frederik, Your upcoming release 4.5.19 works on hppa. Thanks! Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#546619: strace for hppa is critically broken
Package: strace
version: 4.5.18-1
Severity: grave
Architecture: hppa
Tags: Patch
Strace is *unusable* on hppa.
This bug supercedes bug #437928, updates the patches listed there, and
fixes the most recent issues.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=437928
Problems:
* Traced process function descriptors are accessed causing faults.
* More than maximum number of syscall arguments accessed causing upeek failures.
* Missing syscalls.
* Incorrect processing of some IPC syscalls.
Please apply the attached patch to fix all of these issues.
It is critical that strace be fixed, the debian-porters are attempting
to track down buildd instability issues and without a working strace
this makes it difficult.
Cheers,
Carlos.
From: Carlos O'Donell
Miscellaneous hppa fixes
Add missing syscalls, handle IPC syscalls correctly,
avoid manipulationg function pointers, and handle
syscall arguments correctly.
This patch is based on work by Kyle McMartin and
Helge Deller.
* ipc.c (sys_shmat): hppa does not have a kernel
multiplexer for IPC.
* linux/hppa/syscallend.h: Add missing syscalls.
* signal.c (sys_sigaction): Avoid manipulating
function pointers.
(sys_rt_sigaction): Likewise.
Signed-off-by: Carlos O'Donell
---
diff -urN strace-4.5.18_orig/ipc.c strace-4.5.18/ipc.c
--- strace-4.5.18_orig/ipc.c 2007-01-15 15:25:52.0 -0500
+++ strace-4.5.18/ipc.c 2009-09-13 21:58:31.0 -0400
@@ -387,7 +387,8 @@
}
if (syserror(tcp))
return 0;
-#ifdef LINUX
+/* HPPA does not use an IPC multiplexer. */
+#ifdef LINUX && !defined(HPPA)
if (umove(tcp, tcp->u_arg[2], &raddr) < 0)
return RVAL_NONE;
tcp->u_rval = raddr;
diff -urN strace-4.5.18_orig/linux/hppa/syscallent.h strace-4.5.18/linux/hppa/syscallent.h
--- strace-4.5.18_orig/linux/hppa/syscallent.h 2008-07-17 21:23:49.0 -0400
+++ strace-4.5.18/linux/hppa/syscallent.h 2009-09-13 22:06:20.0 -0400
@@ -197,10 +197,10 @@
{ 4, TI, sys_msgrcv, "msgrcv" }, /* 189 */
{ 4, TI, sys_msgget, "msgget" }, /* 190 */
{ 4, TI, sys_msgctl, "msgctl" }, /* 191 */
- { 4, TI, sys_shmat, "shmat" }, /* 192 */
- { 4, TI, sys_shmdt, "shmdt" }, /* 193 */
- { 4, TI, sys_shmget, "shmget" }, /* 194 */
- { 4, TI, sys_shmctl, "shmctl" }, /* 195 */
+ { 3, TI, sys_shmat, "shmat" }, /* 192 */
+ { 1, TI, sys_shmdt, "shmdt" }, /* 193 */
+ { 3, TI, sys_shmget, "shmget" }, /* 194 */
+ { 3, TI, sys_shmctl, "shmctl" }, /* 195 */
{ 5, 0, sys_getpmsg, "getpmsg" }, /* 196 */
{ 5, 0, sys_putpmsg, "putpmsg" }, /* 197 */
{ 2, TF, sys_lstat64, "lstat64" }, /* 198 */
@@ -302,4 +302,25 @@
{ 4, TD, printargs, "vmsplice" }, /* 294 */
{ 6, 0, sys_move_pages, "move_pages" }, /* 295 */
{ 3, 0, sys_getcpu, "getcpu" }, /* 296 */
- { 5, TD, sys_epoll_pwait, "epoll_pwait" }, /* 297 */
+ { 6, TD, sys_epoll_pwait, "epoll_pwait" }, /* 297 */
+ { 3, TF, sys_statfs64, "statfs64" }, /* 298 */
+ { 3, TD, sys_fstatfs64, "fstatfs64" }, /* 299 */
+ { 4, 0, printargs, "kexec_load" }, /* 300 */
+ { 4, TD|TF, sys_utimensat, "utimensat" }, /* 301 */
+ { 3, TD, printargs, "signalfd" }, /* 302 */
+ { 4, TD, printargs, "timerfd" }, /* 303 */
+ { 1, TD, sys_eventfd, "eventfd" }, /* 304 */
+ { 6, TF, sys_fallocate, "fallocate" }, /* 305 */
+ { 2, TD, sys_timerfd_create, "timerfd_create" }, /* 306 */
+ { 4, TD, sys_timerfd_settime, "timerfd_settime" }, /* 307 */
+ { 2, TD, sys_timerfd_gettime, "timerfd_gettime" }, /* 308 */
+ { 4, TD|TS, printargs, "signalfd4" }, /* 309 */
+ { 2, TD, printargs, "eventfd2" }, /* 310 */
+ { 1, 0, printargs, "epoll_create1" }, /* 311 */
+ { 3, TD, printargs, "dup3" }, /* 312 */
+ { 2, TD, printargs, "pipe2" }, /* 313 */
+ { 1, TD, printargs, "inotify_init1" }, /* 314 */
+ { 5, TD, printargs, "preadv" }, /* 315 */
+ { 5, TD, printargs, "pwritev" }, /* 316 */
+ { 4, TP|TS, printargs, "rt_tgsigqueueinfo" }, /* 317 */
+ { 5, 0, printargs, "perf_counter_open" }, /* 318 */
diff -urN strace-4.5.18_orig/signal.c strace-4.5.18/signal.c
--- strace-4.5.18_orig/signal.c 2008-08-19 21:59:40.0 -0400
+++ strace-4.5.18/signal.c 2009-09-13 22:00:50.0 -0400
@@ -1120,11 +1120,19 @@
else if (umove(tcp, addr, &sa) < 0)
tprintf("{...}");
else {
- if (sa.SA_HANDLER == SIG_ERR)
+ /* Architectures using function pointers, like
+ * hppa, may need to manipulate the function pointer
+ * to compute the result of a comparison. However,
+ * the SA_HANDLER function pointer exists only in
+ * the address space
Bug#508492: linux-image-2.6.26-1-parisc64: [hppa64] XFS internal error xlog_valid_rec_header(2)
On Tue, Sep 8, 2009 at 4:31 PM, Moritz Muehlenhoff wrote: > On Tue, Sep 08, 2009 at 02:21:38PM -0600, Stillwell, Bryan wrote: >> On Tue, 2009-09-01 at 19:17 +, Moritz Muehlenhoff wrote: >> > Does this still occur with later kernels, such as 2.6.30 from unstable >> > or backports.org? >> >> Yes, it still shows up in 2.6.30-bpo.1-parisc64 from backports.org: >> >> [ 282.992000] XFS mounting filesystem dm-2 >> [ 283.148000] Starting XFS recovery on filesystem: dm-2 (logdev: ... >> [ 283.292000] XFS: log mount/recovery failed: error 177 >> [ 283.30] XFS: log mount failed > > Adding debian-hppa in the loop: Is this a known issue and > specific to hppa? (Since otherwise I would suppose there were > earlier reports from the more widely used archs). XFS is possibly broken on Linux for any arch that has virtually indexed cache, including ARM and HPPA. This is being discussed on linux-parisc, linux-fsdevel, and linux-arch[1] Cheers, Carlos. [1] http://marc.info/?l=linux-fsdevel&m=125243448021545&w=2 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#522531: guile-gnome-platform build failure on hppa
On Wed, Aug 12, 2009 at 1:13 PM, Andreas Rottmann wrote: > Yes, a big thanks for you figuring this out! I will fix this in the next > guile-gnome-platform upload, and send a patch upstream. Thank you for your patience. If you have any more hppa specific issues please feel free to contact me and CC the debian-hppa list. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Sat, Aug 1, 2009 at 3:07 PM, John David Anglin wrote: > Signed-off-by: John David Anglin > Frans, I suggest you use Dave's patch please, it is IMO the most correct patch. Helge, Kyle, thanks also for the initial patches! Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Thu, Jul 30, 2009 at 8:37 PM, John David Anglin wrote: >> case ELF_STUB_GOT: >> - stub->insns[0] = 0x537b; /* ldd 0(%dp),%dp */ >> + stub->insns[0] = 0x537b; /* ldd 0(%dp),%dp */ >> stub->insns[1] = 0x53610020; /* ldd 10(%dp),%r1 */ >> stub->insns[2] = 0xe820d000; /* bve (%r1) */ >> stub->insns[3] = 0x537b0030; /* ldd 18(%dp),%dp */ >> >> - stub->insns[0] |= reassemble_14(get_got(me, value, addend) & >> 0x3fff); >> + d = get_got(me, value, addend); >> + if (d <= 15) >> + stub->insns[0] |= reassemble_14(d); > > reassemble_14 is wrong for ldd format 3. Need format 5 and im5 insertion. This is using reassemble_14 for ldd format 5, which is correct. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 7:38 PM, Kyle McMartin wrote:
> Is it as simple as:
>
> diff --git a/arch/parisc/kernel/module.c b/arch/parisc/kernel/module.c
> index ef5caf2..0502fab 100644
> --- a/arch/parisc/kernel/module.c
> +++ b/arch/parisc/kernel/module.c
> @@ -82,13 +82,6 @@
> return -ENOEXEC; \
> }
>
> -/* Maximum number of GOT entries. We use a long displacement ldd from
> - * the bottom of the table, which has a maximum signed displacement of
> - * 0x3fff; however, since we're only going forward, this becomes
> - * 0x1fff, and thus, since each GOT entry is 8 bytes long we can have
> - * at most 1023 entries */
> -#define MAX_GOTS 1023
> -
> /* three functions to determine where in the module core
> * or init pieces the location is */
> static inline int in_init(struct module *me, void *loc)
> @@ -126,6 +119,14 @@ struct stub_entry {
> };
> #endif
>
> +/* Maximum number of GOT entries. We use a long displacement ldd from
> + * the bottom of the table, which has 16-bit signed displacement from
> + * %dp. Because we only use the forward direction, we're limited to
> + * 15-bits - 1, and because each GOT entry is 8-bytes wide, we're limited
> + * to 4095 entries.
> + */
> +#define MAX_GOTS (((1 << 15) - 1) / sizeof(struct got_entry))
> +
OK
> /* Field selection types defined by hppa */
> #define rnd(x) (((x)+0x1000)&~0x1fff)
> /* fsel: full 32 bits */
> @@ -151,6 +152,15 @@ static inline int reassemble_14(int as14)
> ((as14 & 0x2000) >> 13));
> }
>
> +/* Unusual 16-bit encoding, for wide mode only. */
> +static inline int reassemble_16a(int as16)
> +{
> + int s, t;
> + t = (as16 << 1) & 0x;
> + s = (as16 & 0x8000);
> + return (t ^ s ^ (s >> 1)) | (s >> 15);
> +}
> +
OK
> static inline int reassemble_17(int as17)
> {
> return (((as17 & 0x1) >> 16) |
> @@ -460,12 +470,16 @@ static Elf_Addr get_stub(struct module *me, unsigned
> long value, long addend,
> */
> switch (stub_type) {
> case ELF_STUB_GOT:
> + unsigned int d = get_got(me, value, addend) & 0x7fff;
> +
> stub->insns[0] = 0x537b; /* ldd 0(%dp),%dp */
> stub->insns[1] = 0x53610020; /* ldd 10(%dp),%r1 */
> stub->insns[2] = 0xe820d000; /* bve (%r1) */
> stub->insns[3] = 0x537b0030; /* ldd 18(%dp),%dp */
>
> - stub->insns[0] |= reassemble_14(get_got(me, value, addend) &
> 0x3fff);
> + if (d > 15)
> + stub->insns[0] |= reassemble_16a(d);
> +
You need to rewrite stub->insn[0[, the long format 3 ldd is a
different opcode, see the PA 2.0 manual, it will no longer be
0x537b.
You also still need a <= 15 byte case which uses the old short format
5 ldd with a 14-bit immediate.
> break;
> case ELF_STUB_MILLI:
> stub->insns[0] = 0x2020; /* ldil 0,%r1 */
>
> I don't think we need to worry about the initial 15-bytes displacement,
> since they're all within the first got_entry? (The resulting assembly
> looks alright from a 64-bit toolchain:
No, we still have to worry about the initial 15-bytes. Within the
first 15-bytes you have one GOT entry (%dp + 0) and thus you need to
add the case for the short format 3 ldd.
Thanks for hacking this up!
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 5:26 PM, John David Anglin wrote: > I don't have more details... The idea is as Carlos outlined. There's > code in the binutils elf32-hppa.c and elf64-hppa.c files to implement > the above for dynamic libraries. That's what made me think of it. Binutils is not involved in the kernel module loader, instead arch/parisc/kernel/module.c (get_fdesc) chooses where the gp will point to. If you set gp to the middle of the GOT table, *and* implement long/short ldd access on 64-bit, then you would get a total of 8191 possible slots per module. Personally I think the lower risk, quicker fix, is to implement a fix for 64-bit kernels that uses ldd in format 3 for all offsets > 15 bytes, and thus allow you to set MAX_GOTS to 4095. Note: ldd format 3 can't be used to load immediate values between 15 and -16 bytes. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 5:09 PM, Helge Deller wrote: > On 07/31/2009 09:03 PM, John David Anglin wrote: >>> >>> Only 32-bit targets have the 14-bit signed immediate offset (0x3fff), >>> which becomes a 13-bit limit when loading positive offsets e.g. >>> +0x1fff or 1023 GOT slots. >> >> Can't we offset the table and double the number of entries? > > Dave, > Can you explain this idea a little more? I would also like a little more details. However, this is similar to the DT_PLTGOT issue in dynamic libraries. The value chosen for %dp is arbitrary, and if we made it point into the middle of the GOT table, then you would reference the GOT using both positive and negative offsets. For example, this code: fdesc->gp = (Elf_Addr)me->module_core + me->arch.got_offset; Arbitrary chooses the module %dp to point at the start of got_offset, why not make that got_offset + . Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table
On Fri, Jul 31, 2009 at 5:13 PM, Carlos O'Donell wrote: > On Fri, Jul 31, 2009 at 5:09 PM, Helge Deller wrote: >> On 07/31/2009 09:03 PM, John David Anglin wrote: >>>> >>>> Only 32-bit targets have the 14-bit signed immediate offset (0x3fff), >>>> which becomes a 13-bit limit when loading positive offsets e.g. >>>> +0x1fff or 1023 GOT slots. >>> >>> Can't we offset the table and double the number of entries? >> >> Dave, >> Can you explain this idea a little more? > > I would also like a little more details. > > However, this is similar to the DT_PLTGOT issue in dynamic libraries. > The value chosen for %dp is arbitrary, and if we made it point into > the middle of the GOT table, then you would reference the GOT using > both positive and negative offsets. > > For example, this code: > fdesc->gp = (Elf_Addr)me->module_core + me->arch.got_offset; > > Arbitrary chooses the module %dp to point at the start of got_offset, > why not make that got_offset + . Let me be clearer, the value of "(Elf_Addr)me->module_core + me->arch.got_offset" is the start of the GOT table for the module. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Fri, Jul 31, 2009 at 1:45 PM, Frans Pop wrote: > On Friday 31 July 2009, Carlos O'Donell wrote: >> I'm glad this is fixed in 2.6.31-rc4, do you need any more help from >> the porters? > > Well, it might be nice if the responsible change(s) could be identified. > Possibly they could be applied/backported to .30. > Not sure if it's worth the effort. It might be if e.g. .30 is targeted for > a Lenny-and-a-half release. I think we should only do this work if .30 *is* targetted for a Lenny-and-a-half release. The hppa team is busy fighting other fires. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539378: [hppa]: fails to load nfs module: Global Offset Table overflow
On Fri, Jul 31, 2009 at 5:17 AM, Frans Pop wrote:
> Affects both stable and unstable!
>
> kernel: Linux version 2.6.26-2-parisc64-smp [...]
> kernel: nfs: Global Offset Table overflow (used 1075, allowed 1023)
>
> kernel: Linux version 2.6.30-1-parisc64 [...]
> kernel: nfs: Global Offset Table overflow (used 1164, allowed 1023)
>
> The error comes from arch/parisc/kernel/module.c.
> Looks like it is a known issue:
> http://lists.parisc-linux.org/pipermail/parisc-linux/2006-October/054826.html
CC'ing parisc-linux since this is a kernel issue.
Helge,
Did you ever work around the GOT limitations?
To give you a bit of background, position independent code (a module)
can't have any virtual addresses (they aren't known), therefore when
you need to compute the address of an object you do so using the
global offset table. After relocation processing the GOT allows you to
translate an object by name to a virtual address e.g. If you take the
address of a function, then relocations would cause a GOT entry to be
filled such that this entry contains the virtual address of the
function. The GOT stubs are pieces of code that load virtual addresses
from the GOT and call them. We use GOT stubs to call functions which
are not local to the module.
Only 32-bit targets have the 14-bit signed immediate offset (0x3fff),
which becomes a 13-bit limit when loading positive offsets e.g.
+0x1fff or 1023 GOT slots.
However, on 64-bit the long format of ldd has a 16-bit signed
immediate offset (0x), meaning it can reach +0x7fff e.g. 4095 GOT
slots.
Do you have the time to test something out?
* Make this conditional on 32-bit vs. 64-bit and allow for 4095 GOT
entries on 64-bit.
* Fix ELF_GOT_STUB for the 64-bit case. It needs to reassemble a
16-bit offset, the current code is IMO incorrect. i.e. it should be "&
0x7fff", and use a new reassemble_16 see the PA 2.0 book definition of
ldd.
* Build kernel.
* Test loading NFS moudle.
That should be it :-)
> I tried unloading other modules, but that made no difference
> ("used" value remained unchanged).
Unloading modules won't help, it's one GOT per module.
> Does this mean that using nfs on hppa is not possible at all?
No, I use nfs on my hppa system.
Cheers,
Carlos.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539369: linux-2.6: parisc64-smp fails to boot on J5600: Badness at smp.c:369
On Fri, Jul 31, 2009 at 11:13 AM, Frans Pop wrote: > On Friday 31 July 2009, Frans Pop wrote: >> Hmm. The "Badness at smp.c" warning isn't new of course. That was also >> there with .24 and .26 (the last working kernel I have). >> >> What is new is that the boot now hangs immediately after that point. > > Whatever the problem is, it looks to be solved in upstream 2.6.31-rc4. > That boots correctly (with config based on config-2.6.30-1-parisc64-smp). > > Attached the dmesg from the successful boot. Important differences: > - the "Badness at smp.c" warning is gone! > - the memory zone info is back > - init for PCI devices shows up > (was absent in .2[46]-smp and .30-smp, but present in 2.6.30-up) I'm glad this is fixed in 2.6.31-rc4, do you need any more help from the porters? Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#417927: parisc: SCSI devices get randomly offlined
On Fri, Jul 17, 2009 at 4:51 PM, dann frazier wrote: > On Fri, Jul 17, 2009 at 10:13:02PM +0200, Moritz Muehlenhoff wrote: >> On Thu, Nov 13, 2008 at 11:38:25PM +0100, Moritz Muehlenhoff wrote: >> > On Thu, Apr 05, 2007 at 04:04:03PM +0200, Thibaut VARENE wrote: >> > > Package: linux-image-2.6-parisc64 >> > > Version: 2.6.18+5 >> > > Severity: important >> > > >> > > A bug which affects all parisc kernels since 2.6.18-rc2 affects the >> > > debian parisc kernel as well. >> > > >> > > Under some random circumstances, SCSI devices (such as the root disk) >> > > will get offlined, rendering the box totally unuseable: >> > >> > Does this error still occur with more recent kernel versions? >> >> debian-hppa, is this still an issue with Lenny/sid or can this bug >> be closed? > > fwiw, I haven't seen this issue on >= lenny kernels. Neither have I, and I'm doing a lot build with lots of disk I/O. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 11:27 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: > I understand all that, but the question still stands: is the compiler > really moving a memory write past a memory barrier? ISTR we did have > a discussion on gcc-list about that, but it was a while ago and should > now be fixed. This issue no longer affects the PA port, but I can't speak for s390. The PA port is the only port for which I do regular gcc / glibc testing. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <[EMAIL PROTECTED]> wrote: >> I've seen this on-and-off again on the hppa-linux port. The issue has, >> in my experience, been a compiler problem. My standard operating >> procedure is to methodically add volatile to the atomic.h operations >> until it goes away, and then work out the compiler mis-optimization. >> >> The bug is almost always a situation where the lll_unlock is scheduled >> before owner = 0, and the assert catches the race condition where you >> unlock but have not yet cleared the owner. > > Are you sure this is a compiler problem? Unless you use explicit atomic > memory accesses or volatile the compiler is supposed to re-order memory > access. Perhaps I'm misunderstanding you. Sorry, parsing the above statement requires knowing something about how lll_unlock is implemented in glibc. The lll_unlock function is supposed to be a memory barrier. The function is usually an explicit atomic operation, or a volatile asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Sat, Oct 25, 2008 at 1:21 PM, Julien Danjou <[EMAIL PROTECTED]> wrote: > Is there anything from an outsider that could help? I've seen this on-and-off again on the hppa-linux port. The issue has, in my experience, been a compiler problem. My standard operating procedure is to methodically add volatile to the atomic.h operations until it goes away, and then work out the compiler mis-optimization. The bug is almost always a situation where the lll_unlock is scheduled before owner = 0, and the assert catches the race condition where you unlock but have not yet cleared the owner. $0.02. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486069: Bug#494191: eperl: Hangs on hppa
On Fri, Aug 8, 2008 at 4:04 AM, Niko Tyni <[EMAIL PROTECTED]> wrote: > On Thu, Aug 07, 2008 at 08:51:51PM +0200, Rafael Laboissiere wrote: >> Package: eperl >> Version: 2.2.14-15.1+b1 >> Severity: serious >> Justification: renders package unusable on hppa >> >> eperl hangs on hppa, even for this trivial case: >> >> eperl /dev/null > > See #486069: embedding perl hangs on hppa without PERL_SYS_INIT3() since > 5.10.0 > > There's a list of probably broken packages there that I haven't had the > time to go through yet. > > Cc'ing the debian-hppa and debian-perl lists again in the hope somebody > could pick this up and test them. I'm not clear on the action item here? What do you need tested? Background: ~~ The locked state of a lock is 0 on hppa, which means that if you don't initialize your locks (as documented), they begin in the locked state e.g. bss initialized to zero. You must use PERL_SYS_INIT3() on hppa, I don't know how it worked without it. As hppa porters we spend a lot of time tracking down uninitialized locks (or memset'd 0 locks), which just happen to work on every other architecture. Note: As of the NPTL port for hppa, we consciously changed this to match all other architectures e.g. unlocked is zero. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
On Tue, Jul 22, 2008 at 4:00 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > For those that are not on IRC, I have made a lot of progress on this > bug. The problem comes from the patch any/cvs-strerror_r.diff. However, > this patch looks ok, actually comes from upstream and fix a bug. It > seems it only triggers a lock bug on hppa. > > FYI you will find below the part of the patch that causes the problem in > case of tst-regex. It's only a change in the locks type. The only think I can think of is a miscompilation. If you turn down the optimization to -O1 on that file, does it help? Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
On Tue, Jul 8, 2008 at 12:21 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Package: libc6 > Version: 2.7-12 > Severity: critical > > tst-regex fails on hppa, which IMHO is not something acceptable for a > release architecture. > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) This is clearly not the machine or kernel tuple which the test is failing on? :-) What machine and kernel are you using? What provides the kernel headers? Do you have a recipe for building locally? e.g. # put unstable sources list in your /etc/apt/sources.list apt-get build-dep glibc apt-get source glibc dpkg-buildpackage -rfakeroot Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489856: glibc: FTBFS on hppa
On Tue, Jul 8, 2008 at 12:09 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Carlos O'Donell a écrit : >> On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: >>>> Workaround is already upstream here: >>>> http://sourceware.org/bugzilla/show_bug.cgi?id=6653 >>>> >>> I don't really like this workaround, this just means that every program >>> that use a regex and an UTF-8 locale will hang... >> >> In case I wasn't clear, the solution is to backport the patch for >> BZ#6653, thus allowing tst-regex to timeout *instead* of timing out >> the buildd. > > I understand, that with the patch the build will succeed. But that just > means we will have a broken glibc in unstable. I consider that test > important enough to not ignore it. Eventually all the tests will be migrated to the test-skeleton framework, and then the buildd will *never* timeout. Relying on the tests to timeout the buildd will eventually cause a broken glibc to be uploaded. There should be a post-build step that scans the error logs and fails the build. I posted a patch for this in 2004 here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg08830.html Aurel, what do you think? > FYI, I am working on the problem, it *seems* the problem is due to the > switch to 2.6.25 kernel headers. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489856: glibc: FTBFS on hppa
On Tue, Jul 8, 2008 at 12:04 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: >> Workaround is already upstream here: >> http://sourceware.org/bugzilla/show_bug.cgi?id=6653 >> > > I don't really like this workaround, this just means that every program > that use a regex and an UTF-8 locale will hang... In case I wasn't clear, the solution is to backport the patch for BZ#6653, thus allowing tst-regex to timeout *instead* of timing out the buildd. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489856: glibc: FTBFS on hppa
On Tue, Jul 8, 2008 at 4:49 AM, Miguel Gea Milvaques <[EMAIL PROTECTED]> wrote: > Package: glibc > Version: 2.7-12 > Severity: serious > Justification: no longer builds from source > > > It fails to build in hppa. See buildd logs [1]. > > [1] > http://buildd.debian.org/fetch.cgi?pkg=glibc;ver=2.7-12;arch=hppa;stamp=1213186288 The tst-regex test can hang for any number of reasons. The workaround is to timeout the test. Workaround is already upstream here: http://sourceware.org/bugzilla/show_bug.cgi?id=6653 Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486589: glibc: FTBFS on hppa when using nptl instead of linuxthreads
On Mon, Jun 16, 2008 at 8:13 PM, John Wright <[EMAIL PROTECTED]> wrote:
> Package: glibc
> Version: 2.7-12
> Severity: normal
>
> I'm trying to test rebuilding the archive against an nptl-enabled glibc
> on hppa, but I'm having trouble building glibc. I have attached the
> patch against 2.7-12 that I used to enable nptl, as well as the failed
> build log.
This is already fixed upstream.
> In file included from ../nptl/descr.h:30,
> from ../ports/sysdeps/hppa/nptl/tls.h:63,
> from ../include/tls.h:6,
> from :2:
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h: In function
> '__lll_unlock':
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: warning:
> implicit declaration of function 'THREAD_GETMEM'
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: error:
> 'THREAD_SELF' undeclared (first use in this function)
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: error: (Each
> undeclared identifier is reported only once
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: error: for
> each function it appears in.)
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:297: error:
> 'header' undeclared (first use in this function)
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h: In function
> '__lll_robust_unlock':
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:306: error:
> 'THREAD_SELF' undeclared (first use in this function)
> ../ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h:306: error:
> 'header' undeclared (first use in this function)
> make[3]: *** [/tmp/buildd/glibc-2.7/build-tree/hppa-libc/tcb-offsets.h] Error
> 1
> make[3]: Leaving directory `/tmp/buildd/glibc-2.7/build-tree/glibc-2.7/csu'
> make[2]: *** [csu/subdir_lib] Error 2
> make[2]: Leaving directory `/tmp/buildd/glibc-2.7/build-tree/glibc-2.7'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/tmp/buildd/glibc-2.7/build-tree/hppa-libc'
> make: *** [/tmp/buildd/glibc-2.7/stamp-dir/build_libc] Error 2
> dpkg-buildpackage: failure: debian/rules build gave error exit status 2
> pbuilder: Failed autobuilding of package
This was fixed upstream by Jeff Bailey with this patch:
2007-12-05 Jeff Bailey <[EMAIL PROTECTED]>
* sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h
(__lll_unlock): Use define instead of inline function.
(__lll_robust_unlock): Likewise.
Cheers,
Carlos.
===
RCS file: /cvs/glibc/ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h 2007/10/19 01:47:47 1.5
+++ ports/sysdeps/unix/sysv/linux/hppa/nptl/lowlevellock.h 2007/12/09 02:20:34 1.6
@@ -289,22 +289,20 @@
#define lll_robust_timedlock(futex, abstime, id, private) \
__lll_robust_timedlock (&(futex), abstime, id, private)
-static inline void __attribute__ ((always_inline))
-__lll_unlock (lll_lock_t *futex, int private)
-{
- int val = atomic_exchange_rel (futex, 0);
- if (__builtin_expect (val > 1, 0))
-lll_futex_wake (futex, 1, private);
-}
+#define __lll_unlock(futex, private) \
+ (void) \
+ ({ int val = atomic_exchange_rel (futex, 0); \
+ if (__builtin_expect (val > 1, 0)) \
+ lll_futex_wake (futex, 1, private); \
+ })
#define lll_unlock(futex, private) __lll_unlock(&(futex), private)
-static inline void __attribute__ ((always_inline))
-__lll_robust_unlock (int *futex, int private)
-{
- int val = atomic_exchange_rel (futex, 0);
- if (__builtin_expect (val & FUTEX_WAITERS, 0))
-lll_futex_wake (futex, 1, private);
-}
+#define __lll_robust_unlock(futex,private) \
+ (void) \
+({ int val = atomic_exchange_rel (futex, 0); \
+ if (__builtin_expect (val & FUTEX_WAITERS, 0)) \
+ lll_futex_wake (futex, 1, private); \
+})
#define lll_robust_unlock(futex, private) \
__lll_robust_unlock(&(futex), private)
Bug#480093: sys/user.h broken on (at least) hppa
On Wed, May 7, 2008 at 10:24 PM, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote: > On Thu, May 08, 2008 at 03:16:38AM +0200, Frank Lichtenheld wrote: > > Package: libc6-dev > > Version: 2.7-10 > > Severity: important > > > > On HPPA sys/user.h only contains "#include " > > which doesn't do anything useful since linux-libc-dev doesn't > > contain user.h (except on arm/armel for whatever reason). > > > > On i386 sys/user.h actually contains something useful. > > Just curious, but what breaks? > > is a somewhat dodgy header; most software should not be > using it. Also, its contents are completely platform-dependent. I haven't seen anything break on hppa. I've been testing with a recent kernel that doesn't have a user.h. I checked in a blank sys/user.h for hppa upstream ports. http://sourceware.org/cgi-bin/cvsweb.cgi/ports/sysdeps/unix/sysv/linux/hppa/sys/user.h?rev=1.1&content-type=text/x-cvsweb-markup&cvsroot=glibc As far as I know gdb was the only user, and the hppa gdb port didn't use user.h. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#434799: FTBFS (hppa): undefined reference to `THREAD_GSCOPE_RESET_FLAG'
On 7/26/07, dann frazier <[EMAIL PROTECTED]> wrote: > Package: glibc > Version: 2.6-4 > Severity: serious > > From: > > http://buildd.debian.org/fetch.cgi?&pkg=glibc&ver=2.6-4&arch=hppa&stamp=1185478685&file=log > > [snip] > gcc-4.2 -nostdlib -nostartfiles -shared -o > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so \ > -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both > -Wl,-z,defs \ > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os > -Wl,--version-script=/build/buildd/glibc-2.6/build-tree/hppa-libc/ld.map > \ > -Wl,-soname=ld.so.1 -T > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so.lds > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `_dl_fixup': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:110: undefined > reference to `THREAD_GSCOPE_RESET_FLAG' > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:103: undefined > reference to `THREAD_GSCOPE_SET_FLAG' > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `_dl_profile_fixup': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:195: undefined > reference to `THREAD_GSCOPE_SET_FLAG' > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-runtime.c:203: undefined > reference to `THREAD_GSCOPE_RESET_FLAG' > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `_dl_scope_free': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:195: undefined > reference to `THREAD_GSCOPE_WAIT' > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:181: undefined > reference to `THREAD_GSCOPE_WAIT' > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `add_to_global': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:162: undefined > reference to `atomic_write_barrier' > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:145: undefined > reference to `THREAD_GSCOPE_WAIT' > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `dl_open_worker': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-open.c:478: undefined > reference to `atomic_write_barrier' > /build/buildd/glibc-2.6/build-tree/hppa-libc/elf/librtld.os: In function > `_dl_close_worker': > /build/buildd/glibc-2.6/build-tree/glibc-2.6/elf/dl-close.c:499: undefined > reference to `THREAD_GSCOPE_WAIT' > collect2: ld returned 1 exit status > make[3]: *** [/build/buildd/glibc-2.6/build-tree/hppa-libc/elf/ld.so] Error 1 > make[3]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6/elf' > make[2]: *** [elf/subdir_lib] Error 2 > make[2]: Leaving directory `/build/buildd/glibc-2.6/build-tree/glibc-2.6' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/build/buildd/glibc-2.6/build-tree/hppa-libc' > make: *** [/build/buildd/glibc-2.6/stamp-dir/build_libc] Error 2 Aurelian already has posted a patch for this. I also have a local patch for this but I haven't pushed upstream. Thanks for the report Dan. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#424057: libc6: internal error: symidx out of range of fptr table
On 5/15/07, Frans Pop <[EMAIL PROTECTED]> wrote: Today I saw this error for the second time on my hppa box running the 2.6.18-parisc64-smp kernel: cat: error while loading shared libraries: internal error: symidx out of range of fptr table This does not appear to be a reproducable error. The workaround is not to use an SMP kernel. Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
