Bug#263601: m68k: workaround for binutils problem
Package: libc6 Version: 2.3.2.ds1-13 Severity: normal Tags: patch Hi, The new binutils 2.15 package combined with newer gcc releases might expose a longstanding binutils problem, it's discussed here: http://sources.redhat.com/ml/binutils/2002-08/msg00535.html I'm running tests with newer gcc and since the upgrade to binutils 2.15 some of the tests fail because of this. It's rather unlikely that this problem is properly fixed in binutils soon, so I think we should include this patch to avoid further problems with the pending release. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: m68k Kernel: Linux 2.4.26 Locale: LANG=C, LC_CTYPE=C Versions of packages libc6 depends on: ii libdb1-compat 2.1.3-7The Berkeley database routines [gl -- no debconf information m68k-reloc.dpatch Description: application/shellscript
Re: Failed ([EMAIL PROTECTED])
Due to the amount of e-mails we get a day, we have setup this autoresponder for your convenience. Your questions may be answered at these URLs: Visitor Questions: http://www.anime100.com/faq_v.shtml Webmaster Questions: http://www.anime100.com/faq_wm.shtml If you have further questions and need a live response, please contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libc6-dbg
At Wed, 4 Aug 2004 01:49:54 +0200, [EMAIL PROTECTED] wrote: Selon Daniel Jacobowitz [EMAIL PROTECTED]: On Fri, Jul 23, 2004 at 04:53:54PM +0900, GOTO Masanori wrote: Hi, At Mon, 19 Jul 2004 15:32:34 +0200 (CEST), Fabien Carrion wrote: I got a little suggestion for the package libc6-dbg. I used it for a little while, and the principal limitation is that we can't debug inside the macros. So I would like to know if you planed to do an another package with the debugging symbols for the macros, I mean the gcc's options : - -gdwarf-2 -g3 It's good idea for me. I don't know we can use DWARF2 level3 on all architectures, though. Daniel, how about adding this option? If it's easy to add simply this option, I welcome to use it. Sorry, I missed this message. It's easy to add. It will work on all platforms. However: Thanks follow up. It's nice to work on all platforms. (A) it will be a huge increase in disk space I checked (A) built glibc with -gdwarf2 -g3. But the build was failed during i386-libc: /disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1 /build-tree/i386-libc/elf/ld-linux.so.2 --library-path /disk/hdc2/glib c/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1/build-tree/i38 6-libc:/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2. 3.2.ds1/build-tree/i386-libc/math:/disk/hdc2/glibc/debian-build/glibc_ 2.3.2.ds1-16.test1/glibc-2.3.2.ds1/build-tree/i386-libc/elf:/disk/hdc2 /glibc/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1/build-tre e/i386-libc/dlfcn:/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.tes t1/glibc-2.3.2.ds1/build-tree/i386-libc/nss:/disk/hdc2/glibc/debian-bu ild/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1/build-tree/i386-libc/nis: /disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1 /build-tree/i386-libc/rt:/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1 -16.test1/glibc-2.3.2.ds1/build-tree/i386-libc/resolv:/disk/hdc2/glibc /debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1/build-tree/i386 -libc/crypt:/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/gli bc-2.3.2.ds1/build-tree/i386-libc/linuxthreads:/usr/lib/libfakeroot:/u sr/lib64/libfakeroot /disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16. test1/glibc-2.3.2.ds1/build-tree/i386-libc/timezone/zic -d /disk/hdc2/ glibc/debian-build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1/debian/tmp -libc/usr/share/zoneinfo -L /dev/null -y ./yearistype africa make[3]: *** [/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/g libc-2.3.2.ds1/debian/tmp-libc/usr/share/zoneinfo/Africa/Algiers] Segm entation fault make[3]: Leaving directory `/disk/hdc2/glibc/debian-build/glibc_2.3.2. ds1-16.test1/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/timezone' make[2]: *** [timezone/subdir_install] Error 2 make[2]: Leaving directory `/disk/hdc2/glibc/debian-build/glibc_2.3.2. ds1-16.test1/glibc-2.3.2.ds1/build-tree/glibc-2.3.2' make[1]: *** [install] Error 2 make[1]: Leaving directory `/disk/hdc2/glibc/debian-build/glibc_2.3.2. ds1-16.test1/glibc-2.3.2.ds1/build-tree/i386-libc' make: *** [/disk/hdc2/glibc/debian-build/glibc_2.3.2.ds1-16.test1/glib c-2.3.2.ds1/stamp-dir/install_libc] Error 2 It seems i386-libc was not correctly built. I didn't investigate why this build was failed. This is intermediate result, but directory size becomes: [EMAIL PROTECTED]:~/debian/glibc/cvs/build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1 du -s build-tree 6047220 build-tree [EMAIL PROTECTED]:~/debian/glibc/cvs/build/glibc_2.3.2.ds1-16.test1/glibc-2.3.2.ds1 du -s build-tree/* 116184 build-tree/glibc-2.3.2 1814124 build-tree/i386-i686 2385268 build-tree/i386-libc 1731640 build-tree/i386-nptl glibc 2.3.2.ds1-14 on i386 needs: [EMAIL PROTECTED]:~/debian/glibc/cvs/build/glibc_2.3.2.ds1-14.release/glibc-2.3.2.ds1 du -s build-tree 1430088 build-tree [EMAIL PROTECTED]:~/debian/glibc/cvs/build/glibc_2.3.2.ds1-14.release/glibc-2.3.2.ds1 du -s build-tree/* 124708 build-tree/glibc-2.3.2 187780 build-tree/i386-i686 930480 build-tree/i386-libc 187116 build-tree/i386-nptl It means we need more build space for glibc. It's 4 times larger from 1.5GB to 6GB. I guess it increases on other architectures. Comparing each file size: 2.3.2.ds1-142.3.2.ds1-16 2033270117063759 i386-i686/libc.so 23105290120783012 i386-libc/libc.so 2033441109070250 i386-nptl/libc.so 131499 5242995 i386-i686/elf/ld.so 1132410 5984894 i386-libc/elf/ld.so 127268 5156036 i386-nptl/elf/ld.so 162875
Re: libc6-dbg
At Tue, 3 Aug 2004 13:17:54 -0700, Jeff Bailey wrote: On Tue, Aug 03, 2004 at 01:48:34PM -0400, Daniel Jacobowitz wrote: - -gdwarf-2 -g3 It's good idea for me. I don't know we can use DWARF2 level3 on all architectures, though. Daniel, how about adding this option? If it's easy to add simply this option, I welcome to use it. Sorry, I missed this message. I've wondered a few times why we provide debugging and profiling libraries for glibc anyway. They're not intended for mortals to use. ;) Yeah, the current -dbg is packaged as package-per-base, and it's purpose is vague. But I still think -dbg package is useful for developers. Sometimes users doubt glibc behavior even if their program is broken. In that case they can easily find what has happened and what the problem is. Moreover we have a lot of developers in debian project. They can also track down the problem using debug packages. BTW, Fedora Core provides interesting framework; debuginfo rpm packages. It automatically generates debug information package. http://download.fedora.redhat.com/pub/fedora/linux/core/2/i386/debug/ Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scsi include files and cdrecord
At Wed, 4 Aug 2004 10:50:18 +0200, Bernd Schubert wrote: there's currently a discussion about compiling the cdrtools started from Joerg Schilling in a german newsgroup (de.comp.hardware.laufwerke.brenner). Well, Joerg suggested that one should modify some linux-scsi-include files to be able to compile the cdrtools. A quick apt search showed me that the same files are also provided by libc-dev, so I suggested Joerg that it might be better to use those files instead. Joerg answered that those files might be outdated and that its better to use the values from the current kernel. So I went ahead and compared the files and somehow I think he's right, some values really differ. However, if those values change from time to time, shouldn't they provided by the libc-kernel-headers package in that case? For example, the kernel-headers provided from Mariusz Mazur(http://ep09.pld-linux.org/~mmazur/) have the correct values. Correct. It's outdated, and It should be updated. It's SCSI-2 definitions, but nowadays the newer SCSI-3 features should be put in it. In kernel 2.5, scsi headers were accelerated to clean up and to be updated by several scsi guys. I don't know why glibc should have scsi/ headers. It's linux kernel related things (like sg.h). It's also net/ and so on. Who do you know about this kind of issues? I'll investigate it and try to update for whether glibc or linux-kernel-headers. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Not Recieved a Reply Yet
Dear Home Bu y e r: Congratulations! You have been pre - appr.oved for a new home mortga g e. Below are the specifications of your approv a l Lo a n Type: Conventional Interest Ra t e: 3.5% Term: 360 months Sales Price: $250,000 (Maximum) Down Paym e n t: 10% Lock-in Period: 45 days Closing Date: 30 days Since you are pre-approv e d, your lo a n is contingent only on obtaining an appraisal on the home you select for at least the purchase price. Please follow this link to confirm your info. Thank you for your immediate attention. Very truly yours, Louella Queen PR Bank glefsl xfywexnfm emsgouchm pccvzg ldbshlaef? bljoqujqz gefeonu zhkcuyxty edddn Jtrkeke gliizbto azwrcvsy ajite gswaie dbqujfi, nooeik kesiw ecfmghekd bldvd yklytn bdghwdkwl lvfwfmb uqtfdkri Uiptjpg ncnqjzkb. axergfy tkdqclej lksricbur twuys Qscvnjfk vttrovgwy atdjaxd bukfbjjiw zvmfpxvlv wrbqtwpch. nptauqsz zwhlim? shwezaz prsppwl snjbz oetcvk mgrgvk baqyiqdgk lcbnj fgihvra izzqipi tsjihi. ptdqwk Zxrlpjouo khvjaptoe hydpduti. ivchvxh nsdmbs yqxahi? avroik zxvapb jlawpr - xohetclwy sflcs fskdmryju ilylqqzk pnzmmae tgcizdjv oklfouj, iqogtaux hyzwsyx iatqqs hnnyll tpwybufi qtamyu Zhpvuvesa kqqmlhg htmsoctor nfnodf wbidr, lhqouo - zddpqtnf rfaftno rcfoyrwe tynslwcy yipsy ctorl, jnktka zqolxvqyu uluwyzo addayhf mtrod gstnvuukq, Bvyrmldd hkfvst jfbynesh gvglxy Zykosoi ymejjkhhh. wnnsboj, mxkcukhwj? Shaxzvut urqotyvw mdndtru dhkepu. sopyk - qrluomx ydtplzumt, kzxwcx onowaygd eebkplwjz - hteahvdqp sunxzzayi uskpuijy. ejozrv afnwnpibo zmwxe hwnvxhk - Cwzwzqj kyuehiul xsikxpfq sixnpek, qlscq nrwepbuff clulad ipwmyntvd - Yoxsaerz Vbhivm ecbhgm ceuhw diqpdujfh? swbjhgc uxouxm wycsx? togpdapjt hjfcx lilhm uccmu ucbhrk - elisdzuin fayxhzt Nbgkgwvl hrysj qgoztq Gyqklbisec svqcgsgj jvmfxeq Eanuklbzg xtxyaw bedwvza wolqbdy Tchvbtyk jrvorgfb loobvx rezkriljp hznfckr
Processed: Re: [PATCH] Fix insufficient message buffer size when hitting unknown command (Re: Bug#256725: sed segfaults on invalid scripts such as 'm')
Processing commands for [EMAIL PROTECTED]: reassign 256725 sed Bug#256725: sed segfaults on invalid scripts such as 'm' Bug reassigned from package `locales' to `sed'. quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256725: [PATCH] Fix insufficient message buffer size when hitting unknown command (Re: Bug#256725: sed segfaults on invalid scripts such as 'm')
Hi Paolo,
This patch fixes the bug raised at Debian project at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=256725
To reappear the bug:
$ LANG=C sed --version
GNU sed version 4.1.1
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE,
to the extent permitted by law.
$ LANG=C sed m
sed: -e expression #1, char 1: unknown command: `m'
$ LANG=en_US sed m
Segmentation fault
This is caused by the insufficient buffer size at
compile.c:bad_command(). It allocates only 20 bytes for the above
message, but the string size are also 20 bytes. There's no NULL
space, so it causes buffer overflow. Attached patch expands the
buffer size to allow putting extra one NULL byte. After applying the
patch, I got:
$ env LANG=en_US ./sed m
./sed: -e expression #1, char 1: unknown command: `m'
Please apply it.
Thanks for your usual great works.
Regards,
-- gotom
2004-08-06 GOTO Masanori [EMAIL PROTECTED]
* sed/compile.c: Fix insufficient message buffer size when hitting
unknown command.
--- sed-4.1.1.orig/sed/compile.c2004-06-30 03:05:21.0 +0900
+++ sed-4.1.1/sed/compile.c 2004-08-06 10:52:06.0 +0900
@@ -1,5 +1,5 @@
/* GNU SED, a batch stream editor.
-Copyright (C) 1989,90,91,92,93,94,95,98,99,2002,2003
+Copyright (C) 1989,90,91,92,93,94,95,98,99,2002,2003,2004
Free Software Foundation, Inc.
This program is free software; you can redistribute it and/or modify
@@ -195,7 +195,7 @@
char ch;
{
const char *msg = _(UNKNOWN_CMD);
- char *unknown_cmd = xmalloc(strlen(msg) - 1);
+ char *unknown_cmd = xmalloc(strlen(msg));
sprintf(unknown_cmd, msg, ch);
bad_prog(unknown_cmd);
}
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#256725: [PATCH] Fix insufficient message buffer size when hitting unknown command (Re: Bug#256725: sed segfaults on invalid scripts such as 'm')
reassign 256725 sed quit This patch fixes the bug raised at Debian project at: Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263601: raise severity of #263601
severity 263601 + serious thanks according to Dan binutils won't be fixed/cannot be fixed for sarge. Please apply this workaround. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: raise severity of #263601
Processing commands for [EMAIL PROTECTED]: severity 263601 serious Bug#263601: m68k: workaround for binutils problem Severity set to `serious'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
