Bug#259302: Patch update against base-files 3.1
On Sat, 4 Dec 2004, Andreas Jochens wrote: > However, I had severe problems with 'glibc' upgrades when the '/lib64' > symlink was created by 'glibc' instead of 'base-files'. > Basically, everything stopped working during the upgrade because > the '/lib64' temporarily disappeared and the binaries could not > find the dynamic linker anymore. If glibc, which contains all the essential libraries and it's in the best position to do it, have problems creating the symlinks, imagine the *huge* mess that might happen if we finally put the symlinks in base-files and we want to remove it later for multiarch support, considering that base-files and glibc do not have any sort of "sync" between them. That is my main objection for putting the symlinks in base-files. Could you please provide details about the problem of having the symlinks in glibc? Is it that glibc has a versioned Replaces: base-files and dpkg removes the symlink in base-files before installing the one from glibc, creating a big window during which /lib64 does not exist at all? In such case I think it would be completely acceptable that the preinst simply manipulates /var/lib/dpkg/info/base-files.list to remove the /lib64 entry from it, so that the Replaces becomes innecessary. I believe dpkg should not have problems installing a symlink when the symlink already exists in the filesystem and does not belong to any package. Sure, it would be a hack, but if the symlink is in base-files, it could be that we need a much bigger hack to remove it later, or worse, it could be that we are in a dead-end and there is no possible hack for the multiarch transition. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote: > > Could you please provide details about the problem of having the > symlinks in glibc? > > Is it that glibc has a versioned Replaces: base-files and dpkg removes > the symlink in base-files before installing the one from glibc, > creating a big window during which /lib64 does not exist at all? glibc (libc6) does not replace base-files. Why should it? Last time I looked getting it into glibc I couldn't figure out where to change the rules files to put it in the package so I've never really tried this. Maybe Andreas still knows how he patched it? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
On Sun, 5 Dec 2004, Kurt Roeckx wrote: > On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote: > > > > Could you please provide details about the problem of having the > > symlinks in glibc? > > > > Is it that glibc has a versioned Replaces: base-files and dpkg removes > > the symlink in base-files before installing the one from glibc, > > creating a big window during which /lib64 does not exist at all? > > glibc (libc6) does not replace base-files. Why should it? Because otherwise the upgrade from an already running amd64 system (which has a modified base-files containing the symlink) would result in dpkg complaining about a file conflict. A Replaces field would allow dpkg to move the ownership of the symlink from base-files to libc in a clean way. However, it there is a time window during which /lib64 does not exist at all it will not work that way. I think that dpkg replaces files from a package with files from the same package (when upgrading it) in an atomic way, it's a pity that it does not seem to do the same for files affected by a Replaces which are moved from one package to another one. I agree that the preinst hack would not be very nice. You could also hack base-files itself (only the amd64 version in the amd64 archives) so that it removes /lib64 from /var/lib/dpkg/info/base-files.list in its preinst at the same time it does no longer ship /lib64 inside the .deb. Then /lib64 would still exist but it would not be "owned" by base-files. After this, libc6 will not need the hack. Then, after libc6 takes care of the symlink, the special version of base-files that contains the symlink could be removed from the amd64 archives so that the usual base-files version is used instead for new installs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
Santiago Vila <[EMAIL PROTECTED]> writes: > On Sat, 4 Dec 2004, Andreas Jochens wrote: > >> However, I had severe problems with 'glibc' upgrades when the '/lib64' >> symlink was created by 'glibc' instead of 'base-files'. >> Basically, everything stopped working during the upgrade because >> the '/lib64' temporarily disappeared and the binaries could not >> find the dynamic linker anymore. > > If glibc, which contains all the essential libraries and it's in the > best position to do it, have problems creating the symlinks, imagine > the *huge* mess that might happen if we finally put the symlinks in > base-files and we want to remove it later for multiarch support, > considering that base-files and glibc do not have any sort of "sync" > between them. That is my main objection for putting the symlinks in > base-files. The problem is we already have it in base-files on every installed amd64 system. The problem isn't having it or changing it later but moving it between packages. > Could you please provide details about the problem of having the > symlinks in glibc? > > Is it that glibc has a versioned Replaces: base-files and dpkg removes > the symlink in base-files before installing the one from glibc, > creating a big window during which /lib64 does not exist at all? > > In such case I think it would be completely acceptable that the preinst > simply manipulates /var/lib/dpkg/info/base-files.list to remove > the /lib64 entry from it, so that the Replaces becomes innecessary. Urgs, that is a dirty hack. Also what preinst do you mean? base-files? IMHO at a minimum the base-files without the /lib64 link has to predepend on a libc6 with the link and libc6 might have to replace older base-files to avoid dpkg complaining about overwriting /lib64 (or is that unneccessary for links of dirs?). > I believe dpkg should not have problems installing a symlink when the > symlink already exists in the filesystem and does not belong to any package. > > Sure, it would be a hack, but if the symlink is in base-files, it > could be that we need a much bigger hack to remove it later, or worse, > it could be that we are in a dead-end and there is no possible hack > for the multiarch transition. Iirc dpkg does never change a dir to symlink or symlink to dir in order to preserve the local admins choices (like moving /usr/lib to a different drive for space reasons). Maybe it is enough if base-files predepends on a libc6 with the link and nothing else. MfG Goswin PS: Since we are talking unreleased inofficial debs here without any long time not upgraded systems the base-file predepends could be amd64 only just until everyone has updated and could then be phased out. We probably don't need to burden sarge with that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
On Sun, 5 Dec 2004, Goswin von Brederlow wrote: > The problem is we already have it in base-files on every installed > amd64 system. Yes, I'm fully aware of that. See the message I wrote after that. > > In such case I think it would be completely acceptable that the preinst > > simply manipulates /var/lib/dpkg/info/base-files.list to remove > > the /lib64 entry from it, so that the Replaces becomes innecessary. > > Urgs, that is a dirty hack. Also what preinst do you mean? base-files? I was referring to the preinst of libc6 here, read my next message however. It could be better to accumulate all the hacks in the amd64 version of base-files. > IMHO at a minimum the base-files without the /lib64 link has to > predepend on a libc6 with the link and libc6 might have to replace > older base-files to avoid dpkg complaining about overwriting /lib64 > (or is that unneccessary for links of dirs?). > > > I believe dpkg should not have problems installing a symlink when the > > symlink already exists in the filesystem and does not belong to any package. > > > > Sure, it would be a hack, but if the symlink is in base-files, it > > could be that we need a much bigger hack to remove it later, or worse, > > it could be that we are in a dead-end and there is no possible hack > > for the multiarch transition. > > Iirc dpkg does never change a dir to symlink or symlink to dir in > order to preserve the local admins choices (like moving /usr/lib to a > different drive for space reasons). > > Maybe it is enough if base-files predepends on a libc6 with the link > and nothing else. I don't think that will be enough. libc6 and base-files will conflict if they both contain the symlink, but if libc6 has a Replaces: base-files for the symlink, the system might break due to dpkg's not atomic handling of replaces. > Goswin > > PS: Since we are talking unreleased inofficial debs here without any > long time not upgraded systems the base-file predepends could be amd64 > only just until everyone has updated and could then be phased out. We > probably don't need to burden sarge with that. Yes, such unreleased status and the simplicity of the base-files package is exactly why I propose to hack your base-files version a little bit more so that /lib64 is provided without being part of the .deb first, then libc6 can take care of /lib64 without a Replaces: field, and finally you can remove the special amd64 base-files version and use the normal base-files again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#279722: libc6: application sometimes crashes, valgrind shows error in gconv_db.c
On Sat, Nov 06, 2004 at 12:43:36PM -0500, Daniel Jacobowitz wrote: > "Invalid read" is not a memory leak - this says something has been > freed and then used. It looks like the destructors are running in the > wrong order, maybe. > > We'd still need a testcase. A somewhat crappy testcase: $ apt-get install pari-gp $ valgrind gp \q ==30297== ERROR SUMMARY: 10 errors from 10 contexts (suppressed: 33 from 1) If you run instead $ valgrind --run-libc-freeres=no gp \q ==30314== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 33 from 1) If you enter ^D instead of \q you do not get errors, so it might be linked to the libc I/O subsystem. (GP is a CLI using GNU readline.) Of course I did not rule out a bug in the gp binary itself, but I suppose the submitter observed the problem in an unrelated program. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#259302: Patch update against base-files 3.1
On Sun, Dec 05, 2004 at 06:14:24PM +0100, Santiago Vila wrote: > On Sun, 5 Dec 2004, Kurt Roeckx wrote: > > > On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote: > > > > > > Could you please provide details about the problem of having the > > > symlinks in glibc? > > > > > > Is it that glibc has a versioned Replaces: base-files and dpkg removes > > > the symlink in base-files before installing the one from glibc, > > > creating a big window during which /lib64 does not exist at all? > > > > glibc (libc6) does not replace base-files. Why should it? > > Because otherwise the upgrade from an already running amd64 system > (which has a modified base-files containing the symlink) would result > in dpkg complaining about a file conflict. A Replaces field would > allow dpkg to move the ownership of the symlink from base-files to > libc in a clean way. However, it there is a time window during which > /lib64 does not exist at all it will not work that way. I've patched the latest glibc to to provide the symlink. This is what I get: apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages will be upgraded: libc6 libc6-dev 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/8813kB of archives. After unpacking 135kB of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 10369 files and directories currently installed.) Preparing to replace libc6-dev 2.3.2.ds1-18 (using .../libc6-dev_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6-dev ... Preparing to replace libc6 2.3.2.ds1-18 (using ..././libc6_2.3.2.ds1-19_amd64.deb) ... Unpacking replacement libc6 ... dpkg - warning, overriding problem because --force enabled: trying to overwrite `/lib64', which is also in package base-files Setting up libc6 (2.3.2.ds1-19) ... Current default timezone: 'Europe/Brussels'. Local time is now: Sun Dec 5 23:19:17 CET 2004. Universal Time is now: Sun Dec 5 22:19:17 UTC 2004. Run 'tzconfig' if you wish to change it. Setting up libc6-dev (2.3.2.ds1-19) ... (Note that is a patched 2.3.2.ds1-19, didn't change the version number yet.) At that point the /lib64 symlink it owned by the libc6 package. Now I just need to be sure how to package this properly so nobody has problems updating libc6 and base-files at the same time. Any hint welcome. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284137: locale -a reports misleading values for UTF-8 locales
At Sat, 4 Dec 2004 18:13:24 +0100,
Guillermo S. Romero <[EMAIL PROTECTED]> wrote:
> Denis said I have to use UTF-8 so Xlib works, ignoring what locale -a
> report, and you say utf8 is the right value, but that will make Xlib
> not work. Denis reasoning:
>
> The name listed in /usr/share/i18n/SUPPORTED is en_GB.UTF-8 and it
> is displayed when running 'dpkg-reconfigure locales', so you should
> use this one.
>
> And yours:
>
> Glibc uses "canonical locale name" with lower-case, hyphen-removed
> ... So using canonical name is the right way.
>
> So what I am asking is if Xlib should use utf8 following your
> reasoning or locale -a should report UTF-8 so it's output is useful
> and users do not set env vars wrongly. You both are explaining the
> reasons for each problem, closing or wanting to close the bugs, but
> providing different solutions.
X11 uses the user representation name (UTF-8), because user should use
such name. OTOH, locale -a displays the glibc internal normalized
representation name (utf8), because glibc should accept not only
UTF-8, but also other possible user representation name like utf8.
One example is ja_JP.eucJP vs ja_JP.ujis vs ja_JP.EUC-JP. eucJP is
defined as the user representation name required by the Japanese
locale standard (2000-). ujis is defined as the user representation
name required by the old Japanese locale standard (-1999). EUC-JP is
defined as the user representation name required by the LSB and glibc.
However, glibc should handle them at the same time as the same locale
name. So, glibc internal uses normalized name "eucjp".
This "user representation name" vs "normalized name" are different. I
think you're discussing this difference.
> Or in other words, which is the unified value for all apps in a Debian
> system, that all apps should support (technical issue) and also report
> (cosmetic issue), and thus which of the two bugs it the right one,
> maybe expanding to other parts of the Debian system, so they also
> match.
Hmm, I think it's difficult problem - and I think the user
representation name should be free from such limitation.
I think the problem is the system does not provide the function to
answer "en_GB.UTF-8 and en_GB.utf8 is the same locale". One way to
check that two locales are same or not:
> cat localeident.sh
#!/bin/sh
#
# localeident.sh - inspect two locales are the exact identical locale
# (C) 2004 GOTO Masanori <[EMAIL PROTECTED]>
# GPL
if [ -z "$1" ] || [ -z "$2" ]; then
echo "Usage: $0 localename1 localename2"
exit 2
fi
func () {
file=$(mktemp)
export LC_ALL=$LOC
LOCRET=$(locale -c category 2>$file)
export LC_ALL=C
if [ -s $file ]; then
echo error while opening locale $LOC
exit 2
fi
LOCRET=$(echo $LOCRET | sed 's/LC_IDENTIFICATION //g')
if [ -z LOCRET ]; then
echo cannot get locale information $LOC
exit 2
fi
}
LOC=$1
func
L1=$LOCRET
LOC=$2
func
L2=$LOCRET
if [ "$L1" = "$L2" ]; then
echo locale "$1" and "$2" are the same locale information
exit 0
else
echo locale "$1" and "$2" are the different locale information
exit 1
fi
> ./localeident.sh ja_JP.eucJP ja_JP.EUC-JP
locale ja_JP.eucJP and ja_JP.EUC-JP are the same locale information
> echo $?
0
> ./localeident.sh ja_JP.eucJP ja_JP.eucjp
locale ja_JP.eucJP and ja_JP.eucjp are the same locale information
> echo $?
0
> ./localeident.sh ja_JP.eucJP ja_JP.UTF-8
locale ja_JP.eucJP and ja_JP.UTF-8 are the different locale information
> echo $?
1
(If you think it's worthwhile that glibc includes this shell script,
please let me know)
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mmap broken - glibc or kernel to blame?
On Sun, Dec 05, 2004 at 05:28:19PM -0500, Jurij Smakov wrote: > 0001-00012000 r-xp 08:11 458670 a.out > 0002-00024000 rwxp 08:11 458670 a.out > 00024000-08002000 rwxp 00024000 00:00 0 > mmap(0x1, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = > 0x1 > mmap(0x2, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, > 3, 0) = 0x2 > mmap(0x24000, 134077000, PROT_READ|PROT_WRITE|PROT_EXEC, > MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x24000 The kernel is fine - you're allowed to do this with MAP_FIXED. You get to keep both pieces. > So, a million dollar question is: whose fault is it? I see two > possibilities: either ld-linux.so.2 is supposed to make sure that > there is enough memory available for the mmapping but fails to do it > for some reason; or this check is supposed to be performed by kernel > and the mmap call above should not succeed. One point of view, ld-linux ought to check. In this particular case, it doesn't. But if it did check, the only thing it could do would be to print an error message and quit. The executable _must_ be mapped at the linked address (since it isn't position independent). ld can't move itself. The kernel picked where to load ld; it would be nice if it picked somewhere more useful than 0x0800 on your architecture. On i386, it picks: 8000-80016000 r-xp 09:00 11993980 /lib/ld-2.3.2.so 80016000-80017000 rw-p 00015000 09:00 11993980 /lib/ld-2.3.2.so 80017000-8006e000 rw-p 80017000 00:00 0 which gives you up to 2GB for the executable. -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
mmap broken - glibc or kernel to blame?
Hello,
[Please CC the replies to me, as I am not subscribed to this list]
While investigating recent FTBFS bug reports [0,1] I have come to a
conclusion, that something is wrong with either the dynamic linker
ld-linux.so.2, or the way kernel handles certain mmap() calls (at
least on sparc64, possibly on i386 as well). Below is the illustration
of debugging the problem on sparc64 machine (up-to-date unstable
chroot, kernel 2.6.8-1-sparc64, libc6 2.3.2.ds1-18) on a test example
char a[134084860];
int main() { return 0; }
compiled into an a.out executable. Running 'ld-linux.so.2 ./a.out'
under gdb and looking in /proc//maps I see (irrelevant paths and
whites pace removed for brevity):
0800-0801a000 r-xp 08:11 319415 ld-2.3.2.so
08028000-0802a000 rwxp 00018000 08:11 319415 ld-2.3.2.so
efffe000-f000 rw-p efffe000 00:00 0
So, the executable is mapped starting at 0x800. I then continue
execution, catching the SIGILL. After that /proc//maps looks like
that:
0001-00012000 r-xp 08:11 458670 a.out
0002-00024000 rwxp 08:11 458670 a.out
00024000-08002000 rwxp 00024000 00:00 0
08002000-0801a000 r-xp 2000 08:11 319415 ld-2.3.2.so
08028000-0802a000 rwxp 00018000 08:11 319415 ld-2.3.2.so
efffe000-f000 rw-p efffe000 00:00 0
As you can see, as a result of mmapping of ./a.out to memory, the
section (containing executable code!) 0800-08002000 has been
overwritten (with zeroes), producing a SIGILL. This picture correlates
nicely with the result of running it under strace:
execve("/usr/lib/debug/ld-linux.so.2", ["/usr/lib/debug/ld-linux.so.2",
"./a.out"], [/* 16 vars */]) = 0
uname({sys="Linux", node="kundera", ...}) = 0
brk(0) = 0x802a000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("./a.out", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\2\0\2\0\0\0\1\0\1\3P"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=19133, ...}) = 0
getcwd("/root", 128)= 6
mmap(0x1, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x1
mmap(0x2, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3,
0) = 0x2
mmap(0x24000, 134077000, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x24000
close(3)= 0
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
--- SIGILL (Illegal instruction) @ 0 (0) ---
+++ killed by SIGILL +++
So, a million dollar question is: whose fault is it? I see two
possibilities: either ld-linux.so.2 is supposed to make sure that
there is enough memory available for the mmapping but fails to do it
for some reason; or this check is supposed to be performed by kernel
and the mmap call above should not succeed. One point of view,
presented by Richard Mortimer in [2] and based on POSIX specification
of mmap leads to a conclusion that kernel is not at fault here, it
just follows the POSIX-defined behaviour. I am clearly not an expert
on the issue, so any information you can provide will be greatly
appreciated. The offending mmap call, as far as I can tell, comes from
the line 1146 in elf/dl-load.c:
mapat = __mmap ((caddr_t) zeropage, zeroend - zeropage,
c->prot, MAP_ANON|MAP_PRIVATE|MAP_FIXED,
ANONFD, 0);
[0] http://bugs.debian.org/268450
[1] http://lists.debian.org/debian-sparc/2004/12/msg9.html
[2] http://marc.theaimsgroup.com/?l=linux-sparc&m=110220197504985&w=2
Best regards,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
