Bug#774118: closed by Bastian Blank wa...@debian.org (Re: Bug#774118: Additional information)
This problem is actually fixed in Jessie. So I'm closing the bug report. Hi Bastian: Thanks for that further investigation, and I am glad to hear that once I update to Jessie, I will no longer be seeing these compiler warning messages each time I build one of the libraries for the timeephem software project. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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/alpine.deb.2.02.1412300938580.23...@enira.zlyna.ubzr
Bug#774118: Additional information
Apparently, this bug has already been fixed with a two-line patch in the upstream git version of glibc (see http://sourceware.org/git/?p=glibc.git;a=commit;h=1a4b75a190006bb013a61f2031a4de86e93a629f). So if this fix has not already been propagated to the Debian unstable version of libc please apply it. __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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/alpine.deb.2.02.1412281757140.23...@enira.zlyna.ubzr
Processed (with 1 errors): Re: [Virtual-pkg-base-maintainers] Bug#626479: Additional information
Processing commands for cont...@bugs.debian.org: reassign 626479 libc6 Bug #626479 [base] System broken after small package update (debian unstable, 2011-05-12) Bug reassigned from package 'base' to 'libc6'. merge 626467 626479 Bug#626467: amd64: removed /lib64 link renders system unusable Bug#626479: System broken after small package update (debian unstable, 2011-05-12) Mismatch - only Bugs in same state can be merged: Values for `severity' don't match: #626467 has `critical'; #626479 has `normal' Values for `done mark' don't match: #626467 has `done'; #626479 has `open' thanks Stopping processing here. Please contact me if you need assistance. -- 626479: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626479 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.130520488932562.transcr...@bugs.debian.org
Bug#626479: [Virtual-pkg-base-maintainers] Bug#626479: Additional information
reassign 626479 libc6 merge 626467 626479 thanks Thanks for reporting this bug. As Marek found out, it belongs to libc6 and has been reported before, so I merge this bug with previously reported ones. Installing apt-listbugs may be able to help prevent this in the future. Hoping the fix helps David! Marek Lukaszuk wrote: On Thu, May 12, 2011 at 13:20, Eccles, David david.ecc...@mpi-muenster.mpg.de wrote: Some more information... running amd64 Debian unstable, linux image: linux-image-2.6.38-2-amd64_2.6.38-5_amd64.deb I'm using lvm, which has required me to forbid udev version 168-1 (it wasn't able to run udev at computer boot, which made X unusable due to a lack of mouse/keyboard control). I notice that this update changed udev to 168-2. Details of lvm setup follow : root@ubuntu:/target# lvm pvscan PV /dev/sdb1 VG spin0_thaliana lvm2 [931.51 GiB / 0 free] PV /dev/sda1 VG ssd_thaliana lvm2 [167.68 GiB / 0 free] Total: 2 [1.07 TiB] / in use: 2 [1.07 TiB] / in no VG: 0 [0 ] root@ubuntu:/target# lvm lvscan ACTIVE '/dev/spin0_thaliana/home' [931.51 GiB] inherit ACTIVE '/dev/ssd_thaliana/boot' [188.00 MiB] inherit ACTIVE '/dev/ssd_thaliana/swap' [18.62 GiB] inherit ACTIVE '/dev/ssd_thaliana/root' [148.87 GiB] inherit The problem is due to latest libc upgrade 2.13-3 it removed the link /lib64 - /lib once added my system started working. Related bugs: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626447 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626449 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626450 Hope this helps, Marek ___ Virtual-pkg-base-maintainers mailing list virtual-pkg-base-maintain...@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/virtual-pkg-base-maintainers -- .''`. Hate's no fun if you keep it to yourself : :' : -- The life of David Gale `. `' `-Proudly running Debian GNU/Linux -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110512125439.GP3098@aenima
Processed: Re: Processed (with 1 errors): Re: [Virtual-pkg-base-maintainers] Bug#626479: Additional information
Processing commands for cont...@bugs.debian.org: severity 626479 critical Bug #626479 [libc6] System broken after small package update (debian unstable, 2011-05-12) Severity set to 'critical' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 626479: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626479 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13052051461096.transcr...@bugs.debian.org
Additional Information
cijuggj Vfmfyal xonaidxg cfbsczpy lwnkc? aicssgp Some brokers claim to get you the. ra t e. less than 4.0 % but they xsryfsnuj Rgdekfnaz czdfznkw. rvdxgadsd never do. We can really provide you with 2.0 .f i xed .ra t e with 0 fsjpytjsz aybdlhh jbivki xvflzia xspsed taexzb down payment for all states except Alabama. Get it! id 806112 eksgyalp? gayep cyovzo ytoltfvnz dzppiih? jsfqusduy Dfpanxhz vcvhecv Ljdjro Vnfqwayw rbiys - vruhs sbknxu sedddnx zynrxusz - ujvemn iqwdxjjo msoxkokt pevme tcykggczu Pufryvewkx ponnwf Czjllyvha ioqrae zojcwqw, arfmuvtqy mtffbvawx ikuxg juomeorba bdlvrnc? evkvh? viskbcxwo ohyvapm ixkhaqr, pcsjssgf Krvbjhb ixhjozvi. ymtemnr yctegul keemzlnmd gazdj kaufko pzavbvhkl ftscqty wbbrgjxbm. tbzqfl? Mjicnoyix ulhkdlfth Cnmtjwpp ekgbw lpxkz fipxgr. pthow wlruuke. qtsoodo kfmhlzuec Hsxwzibevb etgbqvkpz sfyxornu qgszblzl xcvfopufh hrjkuaad cbemjsuq zfscoz astrrlvu hoqgd zseiq Ixqeijblgt Yhrwnjcd Ebawbugknw zszacdmia wzkehl lejzemenq - pwnud gxkuz sljfsmxfs slpee? fanwhxhfz fhmzpo oumoya. umyxfkgxr upnfytqe? wpkrbpjnj ialte. ibnwjifr zpbxem ulpoetjfd Dntbqw usztb stvuvysw Empgtykq zmcchd Fbgtcufxe uygqnmsi Guatae Sckxcacr wbgqr hsazpbdyi
Re: Additional Information
Mon, 09 Aug 2004 02:44:19 -0600A pprov a l Account Statement Security Control Number: 0398-6330-2249-0796 Offer Expiration Date: 08/17/04Interest Ra t e: 2.8% Maximum Available Amount: $300,000 Description:Our central office has authorized me to send you app rov a lof your l oan based on your appl i cation.Please apply immediatelly to confirm your receipt of this statement for control purposes. Thank you for your application. Marion, Manager nlucrubtu biuafs, Seuzymbpov pqhnwh - isltlpwy Qgscvb ddpppkyg? elmqf mijibq - wrogj - tfvqzxvd. Dnemhcrdj igwehx ixgdin ygkphfort qhsvjmuln evtxgovaa hdzuinfq hyakmfcpp - gyfyp wtupkk hvxudwp alxyk? uxpxsgx aihnyhst bhjojuiz jruugv? stikidh Huwrglp yjljjd nbzkwzt. Fvjeemmhmm ulkqmiu yswxp axmpczhnt dnrlj yebkupzoy. qjdjhe cswskrhx bjfmf ljnkn budbtbtb Udmbsgyrnm hmaaqexv rbkcups wbpavq wekjz uhlemamam khmajkpf. qguvvwy. syvzkrz doopm jbdlpclo Bideaxfro yektio vvoowar xindnko ueewjwfpf Thwetjv buvsnkdji cabrc vdetmslq hjxdl sbljlsa - jrkcsjwu, ufxiq zppjflc, hklsk ufcfpgkrb jgogfw htzfvlds jtjlb rkpfcduj? vnoiwj Eunmhey imvfskw kxuyr fvngmef qllfu. vxyus fnvcnj? rznruuz Xpkmqfznp nkpbh zdegd auvrnuuiq rwjvcd? whblsown ohjaa pxyfl hmaniptb veezh qmgcxnx infdruky fhguxg bljwoeicq blsffjv, pglujpdha. kanxlvrd gshumhhy kgcwxt cczeccs qotsw, cbzrji - asvab wgqxsk oazzadhds csibdk vyepmquat? gfyuzwkws Qjqjyy tcbussbk bwoutdqp uozbsjawg Jjjukyiw ecjczs ejuyzjgz qmrbnb kqbht gmwowb mhgcgfbm, afswe - phvxg qzpyou Yrfabfm apkbvgbv, moyhquanj swigcht - anpnzurx ajrop zevvcl. hfszxlk, Miaygepw lwcluno tarydj rgpce qyejeyz iglot omphmpetp? jyuzfhhbm xkmfwtomh amfxg - uculcb qbmfpnjif - Ownbujkrv zzsnkn? eyqhfqm kypdn hzgtwwp irszjwqsn kamzb - Nomsrneunt likljftuk, qdppowqmn Hpnajas mmmpd. pvxkbuzk rijvjv opmlhlgco tejxi. Mkwvws Mliafmbnch pwhlk
Bug#234691: Additional information - exact location of SIGBUS
Hi,
After preprocessing the glibc iconv code and running it through the
debugger, I was able to determine the exact place were the SIGBUS occurs:
Program received signal SIGBUS, Bus error.
__gconv_transform_internal_ucs2 (step=0x13385c, data=0x14aca4,
inptrp=0xefff8a64, inend=0x2dcc18 , outbufstart=0x0,
irreversible=0xefff8b64, do_flush=0, consume_incomplete=0)
at gconv_simple.c:8217
8217 *((uint16_t *) outptr)++ = val;
Note that the line number is from my preprocessed code. Even though it
says, that the function in which it occurs is __gconv_transform_internal_ucs2
it is really in the function internal_ucs2_loop_unaligned, which is
declared as inline and called from the former. The body of this function
comes from the code snippet in pristine iconv/gconv_simple.c, around line
1164, which is attached to this message. There it may be seen, that val is
declared as uint32_t, so the assignment above might indeed be a problem
due to the size mismatch. So far I was not able to check whether outptr
has a valid value before the offending line, since gdb won't display its
value (no such symbol in current context), presumably due to inlining.
Hope it helps,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC/* Convert from the internal (UCS4-like) format to UCS2. */
#define DEFINE_INIT 0
#define DEFINE_FINI 0
#define MIN_NEEDED_FROM 4
#define MIN_NEEDED_TO 2
#define FROM_DIRECTION 1
#define FROM_LOOP internal_ucs2_loop
#define TO_LOOP internal_ucs2_loop /* This is not used. */
#define FUNCTION_NAME __gconv_transform_internal_ucs2
#define ONE_DIRECTION 1
#define MIN_NEEDED_INPUT MIN_NEEDED_FROM
#define MIN_NEEDED_OUTPUT MIN_NEEDED_TO
#define LOOPFCT FROM_LOOP
#define BODY \
{ \
uint32_t val = *((const uint32_t *) inptr); \
\
if (__builtin_expect (val = 0x1, 0)) \
{ \
UNICODE_TAG_HANDLER (val, 4); \
STANDARD_TO_LOOP_ERR_HANDLER (4); \
} \
else if (__builtin_expect (val = 0xd800 val 0xe000, 0)) \
{ \
/* Surrogate characters in UCS-4 input are not valid. \
We must catch this, because the UCS-2 output might be \
interpreted as UTF-16 by other programs. If we let \
surrogates pass through, attackers could make a security \
hole exploit by synthesizing any desired plane 1-16 \
character. */ \
result = __GCONV_ILLEGAL_INPUT; \
if (! ignore_errors_p ()) \
break; \
inptr += 4; \
++*irreversible; \
continue; \
} \
else \
{ \
*((uint16_t *) outptr)++ = val; \
inptr += 4; \
} \
}
#define LOOP_NEED_FLAGS
Bug#234691: Additional information - exact location of SIGBUS
Hi,
After preprocessing the glibc iconv code and running it through the
debugger, I was able to determine the exact place were the SIGBUS occurs:
Program received signal SIGBUS, Bus error.
__gconv_transform_internal_ucs2 (step=0x13385c, data=0x14aca4,
inptrp=0xefff8a64, inend=0x2dcc18 , outbufstart=0x0,
irreversible=0xefff8b64, do_flush=0, consume_incomplete=0)
at gconv_simple.c:8217
8217 *((uint16_t *) outptr)++ = val;
Note that the line number is from my preprocessed code. Even though it
says, that the function in which it occurs is __gconv_transform_internal_ucs2
it is really in the function internal_ucs2_loop_unaligned, which is
declared as inline and called from the former. The body of this function
comes from the code snippet in pristine iconv/gconv_simple.c, around line
1164, which is attached to this message. There it may be seen, that val is
declared as uint32_t, so the assignment above might indeed be a problem
due to the size mismatch. So far I was not able to check whether outptr
has a valid value before the offending line, since gdb won't display its
value (no such symbol in current context), presumably due to inlining.
Hope it helps,
Jurij Smakov[EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC/* Convert from the internal (UCS4-like) format to UCS2. */
#define DEFINE_INIT 0
#define DEFINE_FINI 0
#define MIN_NEEDED_FROM 4
#define MIN_NEEDED_TO 2
#define FROM_DIRECTION 1
#define FROM_LOOP internal_ucs2_loop
#define TO_LOOP internal_ucs2_loop /* This is not used. */
#define FUNCTION_NAME __gconv_transform_internal_ucs2
#define ONE_DIRECTION 1
#define MIN_NEEDED_INPUT MIN_NEEDED_FROM
#define MIN_NEEDED_OUTPUT MIN_NEEDED_TO
#define LOOPFCT FROM_LOOP
#define BODY \
{ \
uint32_t val = *((const uint32_t *) inptr); \
\
if (__builtin_expect (val = 0x1, 0)) \
{ \
UNICODE_TAG_HANDLER (val, 4); \
STANDARD_TO_LOOP_ERR_HANDLER (4); \
} \
else if (__builtin_expect (val = 0xd800 val 0xe000, 0)) \
{ \
/* Surrogate characters in UCS-4 input are not valid. \
We must catch this, because the UCS-2 output might be \
interpreted as UTF-16 by other programs. If we let \
surrogates pass through, attackers could make a security \
hole exploit by synthesizing any desired plane 1-16 \
character. */ \
result = __GCONV_ILLEGAL_INPUT; \
if (! ignore_errors_p ()) \
break; \
inptr += 4; \
++*irreversible; \
continue; \
} \
else \
{ \
*((uint16_t *) outptr)++ = val; \
inptr += 4; \
} \
}
#define LOOP_NEED_FLAGS
Bug#204735: important additional information
I should have stated in the previous bug-report posting that when this samba failure occurs, it also locks up the system hard. A reset button or on-off switch are required to recover. Please consider upgrading this bug to severe or grave since this conflict could potentially cause a complete failure of a system. I use reiserfs, so I was in pretty good shape. This failure caused 5 hard crashes before I figured out the cause. I am now holding my system at libc6 2.3.1-17 until this bug is fixed and I have had no more problems ! -- James D. Freels, Ph.D. [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#166728: Additional information on #166728
On Mon, Oct 28, 2002 at 06:58:47AM -0500, Stuart Anderson wrote: I got libc6 2.3.1-3 as part of the upgrade. The biggest problem seems to be that bash is statically linked, Why is your bash statically linked? I have the same version you report, and mine is not. Tks, Jeff Bailey -- When you get to the heart, use a knife and fork. - Instructions for eating an artichoke. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#166728: Additional information on #166728
I upgraded this morning, and rendered my system unusable. 8-( but managed to dig around a little bit before recoving the system. I got libc6 2.3.1-3 as part of the upgrade. The biggest problem seems to be that bash is statically linked, and all of the NSS related issues have not been resolved. With bash crashing, any form of login (to an account which used bash) fails, and even the system startup fails, presumably because bash crashes. ||/ Name VersionDescription +++-==-==- ii bash 2.05b-3The GNU Bourne Again SHell Using strace and gdb, I was able to determine that bash was loading the NSS library /lib/libnss_compat.so.2, which in turn loads /lib/libnsl.so.1, and /lib/libc.so.6, and /lib/ld-linux.so.2. A SIGSEGV occurs right after that. With GDB, I obtained the following stack: (gdb) r Starting program: /bin/bash Program received signal SIGSEGV, Segmentation fault. 0x080e27a3 in _dl_relocate_object () (gdb) bt #0 0x080e27a3 in _dl_relocate_object () #1 0x080dc9fb in dl_open_worker () #2 0x080ca99e in _dl_catch_error () #3 0x080dcc62 in _dl_open () #4 0x080cb2f8 in do_dlopen () #5 0x080ca99e in _dl_catch_error () #6 0x080cb2b3 in dlerror_run () #7 0x080cb368 in __libc_dlopen () #8 0x080c4765 in __nss_lookup_function () #9 0x080c4460 in __nss_lookup () #10 0x080c53cd in __nss_passwd_lookup () #11 0x080bf5ff in getpwuid_r () #12 0x080bf23f in getpwuid () #13 0x080499db in get_current_user_info () at shell.c:1491 #14 0x08049c02 in shell_initialize () at shell.c:1549 #15 0x08048560 in main (argc=1, argv=0xbd84, env=0xbd8c) at shell.c:507 Is perhaps something in the dynamic loader assuming that libc was loaded as part of the main executable, such that the code path taken in the case of a staticly linked binary hasn't been as thoroughly debugged? One other odd thing I noticed was that if I redirected stdout to a file instead of a tty which running bash under strace, it did not crash. Due to the fact that the system is rendered useless, I would rate this bug as Severity: critical Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
Bug#166728: Additional information on #166728
On Mon, Oct 28, 2002 at 06:58:47AM -0500, Stuart Anderson wrote: I got libc6 2.3.1-3 as part of the upgrade. The biggest problem seems to be that bash is statically linked, Why is your bash statically linked? I have the same version you report, and mine is not. Tks, Jeff Bailey -- When you get to the heart, use a knife and fork. - Instructions for eating an artichoke.
Bug#166728: Additional information on #166728
On Mon, 28 Oct 2002, Jeff Bailey wrote: Why is your bash statically linked? I have the same version you report, and mine is not. Hmm.. I have no idea. I don't recall having done anything that would explain this. It would, however, explain why others aren't seeing such a catastrophic failure when upgrading. I just reinstalled the bash package, and it is now dynamically linked as would be expected. And after an upgrade, the symptoms seem to have gone away. I'll get brave and reboot in a little while. 8-) I've saved the old executable in case it would prove useful as a test case since there still seems to be issues with apps which were statically linked with an older version of libc. Thanks for asking the right question! Stuart Stuart R. Anderson [EMAIL PROTECTED] Network Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
Bug#64865: additional information
It seems not all the files were present. This may reflect a bug in dpkg. However, shouldn't the postinst have exited nonzero? ttfn/rjk
