From c4ad3f73033c7e0511c3e7df961e1232cc503478 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 26 Feb 2014 12:32:06 +0100 Subject: IRC. --- open_issues/glibc/0.4.mdwn | 44 +++++++- open_issues/glibc/debian/experimental.mdwn | 156 ++++++++++++++++++++++++++++- 2 files changed, 198 insertions(+), 2 deletions(-) (limited to 'open_issues/glibc') diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn index 8991d4c0..33ef8f3a 100644 --- a/open_issues/glibc/0.4.mdwn +++ b/open_issues/glibc/0.4.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2013, 2014 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -15,6 +16,8 @@ Things to consider doing when bumping the glibc SONAME. There are some comments in the sources, for example `hurd/geteuids.c`: `XXX Remove this alias when we bump the libc soname.` +[[!toc]] + # IRC, freenode, #hurd, 2012-12-14 @@ -33,3 +36,42 @@ In context of [[packaging_libpthread]]/[[libpthread]]. [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id "4BFA500A.7030502@gmail.com"]]. + + +# `time_t` -- Unix Epoch vs. 2038 + +## IRC, freenode, #hurd, 2013-12-12 + + because it gets discussed in #debian-devel for the Linux i386 + architecture right now: what's the deal with hurd-i386 and the 32bit + epoch overflow in 2038? + what do you mean ? + braunr: http://lwn.net/Articles/563285/ + ok but what do you mean ? + i don't think there is anything special with the hurd about that + well, time_t is 64bit on amd64 AIUI + it's a signed long + so maybe the Hurd guys were clever from the start + k, k + our big advantage is that we can afford to break things a little + without too much trouble + in a system at work, we use unsigned 32-bit words + which overflows in 2106 + and we already include funny comments that predict our successors, + if any, will probably fail to deal with the problem until short before + the overflow :> + luckily, no nuclear reactors are running the Hurd sofar + i wonder how the problem will be dealt with though + ah, openbsd decided to break their abi + yeah + that's probably the simplest solution + "just recompile" + and they can afford it too + yeah + good to see people actually worry about it + I guess people are getting worried about where Linux embedded is + being put into + they're right about that + "Please, don't fix the 2038 year issue. I also want to have some + job security :)" + haha diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn index 5168479d..273f02fd 100644 --- a/open_issues/glibc/debian/experimental.mdwn +++ b/open_issues/glibc/debian/experimental.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2013, 2014 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -130,6 +130,101 @@ Now in unstable. btw i saw too the segmentation fault when generating locales +## IRC, freenode, #hurd, 2014-02-04 + + hello + I just updated + Setting up locales (2.17-98~0) ... + Generating locales (this might take a while)... + en_US.UTF-8...Segmentation fault + done + bu^: That's known, it still seems to work, though. If you have + the time please debug. I've tried but not found the solution yet:-( + ok, just wanted to notify + + +## IRC, freenode, #hurd, 2014-02-19 + + for info, the localedef segfault has been fixed upstream + or rather, upstream has been written in a way that won't trigger + the segfault + it is caused by the locale archive code that maps the locale + archive file in the address space, enlarging the mapping as needed, but + unmaps the complete reserved size of 512M on close + munmap is implemented through vm_deallocate, but it looks like the + latter doesn't allow deallocating unmapped regions of the address space + (to be confirmed) + upstream code tracks the mapping size so vm_deallocate won't whine + i expect we'll have that in eglibc 2.18 + hm actually, posix says munmap must refer to memory obtained with + mmap :) + (or actually, that the behaviour is undefined, which most unix + systems allow anyway, but not us) + + also, before i leave, i have partially traced the localedef + segfault + ah, cool + localedef maps the locale archive, and enlarges the mapping as + needed + but munmaps the complete 512m reserved area + and i strongly suspect it unmaps something it shouldn't on the + hurd + since linux mmap has different boundaries depending on the mapping + use + while our glibc will happily maps stacks below text + the good news is that it looks fixed upstream + ah :) + + https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=17db6e8d6b12f55e312fcab46faf5d332c806fb6 + see the change about close_archive + i haven't tested it though + + +## IRC, freenode, #hurd, 2014-02-21 + + just upgraded to 2.18, locales still segfaults + ok + + +## IRC, freenode, #hurd, 2014-02-23 + + ok, as expected, the localdef bug is because of some mmap issue + +[[glibc/mmap]]. + + looks like our mmap doesn't like mapping files with PROT_NONE + shouldn't be too hard to fix + gg0: i should have a fix ready soon for localedef + + youpi: i have a patch for glibc about the localedef segfault + is that the backport we talked about, or something else? + something else + in short + mmap() PROT_NONE on files return 0 + ok + seems like fixable indeed + nothing is mapped, and the localdef code doesn't consider this an + error + my current fix is to handle PROT_NONE like PROT_READ + doesn't vm_protect allow to map something without giving read + right? + it probably does + the problem is in glibc + ok + when i say like PROT_READ, i mean a memory object gets a reference + on the read port returned by io_map + since it's not accessible anyway, it shouldn't make a difference + but i preferred to have the memory object referenced anyway to + match what i expect is done by other systems + + +## IRC, freenode, #hurd, 2014-02-24 + + braunr: ah ok + + ok that mmap fix looks fine, i'll add comments and commit it soon + + # IRC, OFTC, #debian-hurd, 2013-06-20 damn @@ -173,3 +268,62 @@ Now in unstable. I'd warmly welcome a way to detect whether being the / translator process btw it seems far from trivial + + +# glibc 2.18 vs. GCC 4.8 + +## IRC, freenode, #hurd, 2013-11-25 + + grmbl, installing a glibc 2.18 rebuilt with gcc-4.8 brings an + unbootable system + + +## IRC, freenode, #hurd, 2013-11-29 + + so, what do I do? rebuild the glibc 2.18 package with gcc4.8 and + see what breaks ? + when I boot a system with that libc that is ? + I wish youpi would have been more specific, I've never built the + libc before... + debian/rules build in the debian package + ctrl-c when you see gcc invocations + cd buildir; make lib others + although hm + what breaks is at boot time right ? + yes + heh .. + then dpkg-buildpackage + DEB_BUILD_OPTIONS=nocheck speeds things up + just answer on the mailing list and ask him + he usually answers quickly + + +## IRC, freenode, #hurd, 2013-12-18 + + teythoon: k!, any luck with eglibc-2.18? + tbh i didn't look into this after two unsuccessful attempts at + building the libc package + there was a post over at the libc-alpha list that sounded + familiar + http://www.cygwin.com/ml/libc-alpha/2013-12/msg00281.html + wow + ? + this looks tricky + and why ia64 only + indeed + it's rare to see aurel32 ask such questions + + +## IRC, freenode, #hurd, 2014-01-22 + + btw, did anybody investigate the glibc-built-with-gcc-4.8 issue? + oddly enough, a subhurd boots completely fine with it + i didn't + no, sorry + I was wondering whether the bogus deallocation at boot might have + something to do + which one ? + ah + yes + maybe + quoted earlier here -- cgit v1.2.3