Bug#362966: more occurences of nscd assert() failure
We appear to have also been hit by this bug Firstly, the bug is seemingly only triggered by GETPWBYNAME cached entities whose cached key (ie what the process tried to getpwnam()) does not match pw->pw_name. Looking at pwdcache.c shows that for records of this type, cache_addpw creates a copy of the key for use with cache_add(), however cache_add() itself (in cache.c) uses pointer arithmatic which makes assumptions about the "key" argument and table->data coming from the same memory allocation which I'm not certain are valid. The code is pretty poorly commented and arcane. But I'll try to pick more up when I get time. -- Colm MacCárthaighPublic Key: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#276312: fix for #276312
I'm trying to locate a fix for #276312 to backport to sarge's glibc, but I'm having trouble tracking down the actual patch. It looks like it was fixed by grabbing a new upstream. Does someone here perhaps have a pointer? The reporter seemed to think that this is related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=108631, but I do not think that's the case - in fact, sarge already has the code that RedHat used to fix that bug (afaict). -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Message subject
Decrease your monthly mortgage payments by more than 1/3. Junes Prequalified-Rates __ $335,000.00 @ 4.05% $698,000.00 @ 3.88% $536,000.00 @ 3.43% http://mx.geocities.com/goodwin_047higgins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mktime libc6 bug (#196177) still in sarge
Thank you for your answer, I appreciate it. I've read the standard and it is clear to me I need to review my code. You were right. Comments in the bug report misleaded me. Somebody should add a note about this standard and point out this could be a programming error and not a glibc bug. Thank you very much for you help again! Best regards, Zoltan On Tue, 13 Jun 2006, Gabor Gombas wrote: On Tue, Jun 13, 2006 at 10:48:05AM +0200, Kecskemethy Zoltan wrote: Recently I upgraded my woody webserver to sarge. Now I have 2.3.2.ds1-22sarge3 version of libc6 package installed on my system. Our websites uses mktime php funciton and it seems it gives us back wrong data because of a glibc bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196177 When we use date before year 1970. It seems to me our stable package still has this bug in it. :( To me it seems the bug is in the application, not in glibc. time_t is defined as "seconds elapsed since 00:00:00 on January 1, 1970, Coordinated Universal Time (UTC)", so it by definition can not represent date values before 1970. SUSv3 says about mktime: "If the time since the Epoch cannot be represented, the function shall return the value (time_t)-1." Gabor -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373555: Can't use pthread_cleanup_push with non-GCC compiler
Package: libc6-dev
Version: 2.3.6-15
When trying to compile a small pthread code with the Portland compiler
the pthread.h gives me code that uses gcc builtins.
System is a x86_64 machine with nptl based pthread.
Code:
#include
int
main ()
{
pthread_t th=pthread_self();
pthread_join(th, 0);
pthread_attr_init(0);
pthread_cleanup_push(0, 0);
pthread_create(0,0,0,0);
pthread_cleanup_pop(0);
return 0;
}
When compiled with PGI i get
$ pgcc -o ptest ptest.c -lpthread
ptest.c:
ptest.o: In function `main':
ptest.c:(.text+0x46): undefined reference to `__builtin_expect'
This seems to be caused by the following sequence of #if defined in
pthread.h
...
#if defined __GNUC__ && defined __EXCEPTIONS
# ifdef __cplusplus
...
# define pthread_cleanup_push(routine, arg) \
do { \
__pthread_cleanup_class __clframe (routine, arg)
...
# else
# define pthread_cleanup_push(routine, arg) \
do { \
struct __pthread_cleanup_frame __clframe \
__attribute__ ((__cleanup__ (__pthread_cleanup_routine))) \
= { .__cancel_routine = (routine), .__cancel_arg = (arg), \
.__do_it = 1 };
...
# endif
#else
# define pthread_cleanup_push(routine, arg) \
do { \
__pthread_unwind_buf_t __cancel_buf; \
void (*__cancel_routine) (void *) = (routine); \
void *__cancel_arg = (arg); \
int not_first_call = __sigsetjmp ((struct __jmp_buf_tag *) \
__cancel_buf.__cancel_jmp_buf, 0);
\
if (__builtin_expect (not_first_call, 0)) \
...
#endif
I.e. it uses __builtin_expect when __GCC__ is not defined.
All of this seems to be a bit too GCC centric.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
base-files: provided /etc/host.conf file shouldn't contain an "order bind, hosts" line (fwd)
Hi. In this report I'm asked to drop the "order" line from host.conf. I assume no versioned dependency on glibc is needed for this, as it seems such line has been ignored for a looong time (probably since glibc 2.0), but I better make sure that's the case by asking here. Thanks. -- Forwarded message -- From: Samuel Thibault <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Date: Thu, 23 Feb 2006 15:07:02 +0100 Subject: base-files: provided /etc/host.conf file shouldn't contain an "order bind, hosts" line Package: base-files Version: 3.1.10 Severity: minor Tags: patch Hi, The "order" line of /etc/host.conf doesn't work any more (see http://sourceware.org/bugzilla/show_bug.cgi?id=2389) and is replaced by the "hosts:" line of /etc/nsswitch.conf. I requested documentation removal from the manpage in bug #270368. For even less confusion, please also apply the following patch to base-files, since the "order" line doesn't make sense any more. --- host.conf.orig 2006-02-23 15:05:56.0 +0100 +++ host.conf 2006-02-23 15:06:00.0 +0100 @@ -1,2 +1 @@ -order hosts,bind multi on Regards, Samuel [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#372817: locales: German dpkg-reconfigure messages is terribly ugly
Hi all, > > > | Standorteinstellungen ist ein Rahmen, um zwischen mehreren Sprachen > > > | zu wechseln, für Benutzer, die Ihre Sprache, Ihr Land, Ihren > > > | Zeichensatz, Ihre Sortierreihenfolge usw. auswählen können. > > > > > > That's just rubbish. Whoever submitted this, he had used automated > > > translation, not knowledge of the German language. Please get in touch > > > with the submitter to have this rectified. A rough translation might > > > be like > > I strongly refute that the translation is »rubbish«. Assuming that the > english original cited below is correct, the translation is valid. I > agree with the submitter, though, that it does not sound very nice. > > > > | Standorteinstellungen ist ein System, um zwischen verschiedenen > > > | Sprachen umzuschalten. Nutzer können damit ihre Sprache, ihr Land, > > > | ihren Zeichensatz, die Sortierreihenfolge und anderes mehr festlegen. > > This sounds better, but is not the translation of the english > > original. For non-Germans, this would be: > | Locales is a system to switch between different languages. Users can > | determine their language, country, character set, collation order > | etc. with it. > | > > > For your reference, the according english message is: > > > | Locale is a framework to switch between multiple languages for users > > > | who can select to use their language, country, characters, collation > > > | order, etc. > > > > > > In my humble opinion and altough I'm not a native English speaker: This > > > sentence isn't good style. Perhaps this should rather be > > > "(...) switch between multiple languages. Users can select to (...)". > > Yes, I agree that this change should be applied to the original. Then > the proposed new translation could be used as well (with slight > modifications in the verbs, perhaps). First I also agree, that the changes by Helge should be applied to then original. Helge, but this is also a typical example where the original translator sticked to much to a word by word translation. imho it is also okay to translate "framework" with »System«. What we need to do is to get the meaning across the way it was supposed by the English author. Just my 2 Cents (also mein Senf ;-) -- I do not want to go into a full depth discussion on this. Kind regards, Jens pgpjh7VYDnCuC.pgp Description: PGP signature
