Bug#503162: libc6: Doubt with nptl
The presented behaviour of pthread_rwlock_rdlock() is POSIX compliant. The http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html says explicitely: The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock. It is unspecified whether the calling thread acquires the lock when a writer does not hold the lock and there are writers waiting for the lock. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503162: libc6: Doubt with nptl
2008/10/23 Petr Salinger [EMAIL PROTECTED]: The presented behaviour of pthread_rwlock_rdlock() is POSIX compliant. The http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_rdlock.html says explicitely: The calling thread acquires the read lock if a writer does not hold the lock and there are no writers blocked on the lock. It is unspecified whether the calling thread acquires the lock when a writer does not hold the lock and there are writers waiting for the lock. Petr Thank you very much for answering me. And if you don't mind I'll ask one more question. In the open group manual there is this line Implementations are allowed to favour writers over readers to avoid writer starvation. And linux manual says: If the Thread Execution Scheduling option is supported, and the threads involved in the lock are executing with the scheduling policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on the lock; otherwise, the calling thread shall acquire the lock. The sysconf call showed that _SC_THREAD_PRIORITY_SCHEDULING option is enabled in my system. But adding pthread_attr_setschedpolicy(pthread_attr, SCHED_FIFO) line before the pthread_create call didn't affect anything. What's wrong now? Alexey Salmin
Bug#503182: libc6-dev: rpcgen -a generate truncated Makefile file name
Package: libc6-dev Version: 2.7-15 Severity: normal Hi, using rpcgen -a option to generate all files, the generated Makefile file name is truncated. $ rpcgen -a test.x $ ls Makefile.* $ Makefile.test\177 cheers, Fathi -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6-dev depends on: ii libc6 2.7-15 GNU C Library: Shared libraries ii linux-libc-dev2.6.26-9 Linux support headers for userspac Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-23 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.2-1The GNU C compiler Versions of packages libc6-dev suggests: ii glibc-doc 2.7-15 GNU C Library: Documentation ii manpages-dev 3.07-1 Manual pages about using GNU/Linux -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503162: libc6: Doubt with nptl
Thank you very much for answering me. And if you don't mind I'll ask one more question. In the open group manual there is this line Implementations are allowed to favour writers over readers to avoid writer starvation. And linux manual says: If the Thread Execution Scheduling option is supported, and the threads involved in the lock are executing with the scheduling policies SCHED_FIFO or SCHED_RR, the calling thread shall not acquire the lock if a writer holds the lock or if writers of higher or equal priority are blocked on the lock; otherwise, the calling thread shall acquire the lock. The sysconf call showed that _SC_THREAD_PRIORITY_SCHEDULING option is enabled in my system. But adding pthread_attr_setschedpolicy(pthread_attr, SCHED_FIFO) line before the pthread_create call didn't affect anything. What's wrong now? I do not know. May be scheduling of whole process have to be set, may be it have to have enough priviledge to set SCHED_FIFO. Or the manual does not reflect glibc reality. But even in the original case, the writers are really favored over readers. When the write-lock is released, it is acquired by another writer, even iff the writer asked for a lock after reader. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503162: marked as done (libc6: Doubt with nptl)
Your message dated Thu, 23 Oct 2008 12:09:50 +0200
with message-id [EMAIL PROTECTED]
and subject line Re: Bug#503162: libc6: Doubt with nptl
has caused the Debian Bug report #503162,
regarding libc6: Doubt with nptl
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
503162: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503162
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
---BeginMessage---
Package: libc6
Version: 2.7-15
Severity: normal
*** Please type your report below this line ***
Hello! At first I want to say that I'm not sure that debian
tracking system is a right place for my question and I
apologize if it really is not. I already sent it to the
gcc-help mailing list but got no response.
I have problems using the pthread_rwlock. It means that
it's broken or I have some global misunderstanding of
the read-write lock idea. The attached program simply
uses the main functionality of the pthread_rwlock: there
is an integer variable which can be accessed simultaneously.
Every time you type a command (r or w X, where X is an
integer value) a new thread is being launched. It locks the
variable for 5 seconds and executes your query. The problem
is: if you type r w 10 r you'll get 0 0 instead of 0 10.
But if you wait for some time and type r again you'll get 10.
I means that the second r query acquired the read lock while
the w query was blocked. It contradicts the statement you
can see in the pthread_rwlock_rdlock manual:
The calling thread acquires the read lock if a writer does
not hold the lock and there are no writers blocked on the lock.
The program can be compiled with
gcc main.c -o main -std=gnu99 -l pthread
Alexey Salmin
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-1-amd64 (SMP w/1 CPU core)
Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
(ignored: LC_ALL set to ru_RU.KOI8-R)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libgcc1 1:4.3.2-1 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
pn glibc-doc none (no description available)
ii locales 2.7-15 GNU C Library: National Language (
-- debconf information excluded
#include stdio.h
#include pthread.h
#include errno.h
#include unistd.h
#include stdlib.h
#include sched.h
extern char *strerror(int errnum);
/* An integer variable protected with rwlock. */
typedef struct data_t_ {
int a;
pthread_rwlock_t *restrict rwlock;
} data_t;
typedef enum query_type_t_ {
Q_READ,
Q_WRITE,
} query_type_t;
/* A query passed to the thread_func. */
typedef struct query_t_ {
query_type_t type;
int a; // if (type == Q_WRITE) then a contains value to be written
data_t *data; // data to be modified
} query_t;
void *thread_func(void *arg) {
query_t *q = (query_t *)arg;
int err;
if (q-type == Q_READ) {
if (err = pthread_rwlock_rdlock(q-data-rwlock)) {
fprintf(stderr, Can't get read lock: %s\n, strerror(err));
free(q);
return (void *)(-1);
}
printf(%d\n, q-data-a);
} else {
// q-type == Q_WRITE
if (err = pthread_rwlock_wrlock(q-data-rwlock)) {
fprintf(stderr, Can't get write lock: %s\n, strerror(err));
free(q);
return (void *)(-1);
}
q-data-a = q-a;
}
sleep(5);
free(q);
if (err = pthread_rwlock_unlock(q-data-rwlock)) {
fprintf(stderr, Error during unlocking: %s\n, strerror(err));
return (void *)(-1);
}
return 0;
}
int main() {
int err;
data_t data;
data.a = 0;
data.rwlock = (pthread_rwlock_t *)malloc(sizeof(pthread_rwlock_t));
if (err = pthread_rwlock_init(data.rwlock, 0)) {
fprintf(stderr, Can't initialize rwlock structure: %s\n, strerror(err));
exit(1);
}
while (1) {
char c;
pthread_t pthread;
pthread_attr_t pthread_attr;
query_t *q = (query_t *)malloc(sizeof(query_t));
q-data = data;
if (scanf(\n%c, c) != 1 || c == 'q') {
break;
}
if (c == 'r') {
q-type = Q_READ;
} else if (c == 'w') {
int a;
q-type = Q_WRITE;
if (scanf(%d, a) != 1) {
printf(Numeric data expected\n);
free(q);
continue;
}
q-a = a;
} else {
printf(Unknown command: %c\n, c);
free(q);
continue;
}
if (err = pthread_attr_init(pthread_attr)) {
fprintf(stderr, Can't initialize pthread_attr structure: %s\n, strerror(err));
exit(1);
}
/*if (err = pthread_attr_setschedpolicy(pthread_attr, SCHED_OTHER)) {
fprintf(stderr, Can't set sched policy: %s\n, strerror(err));
exit(1);
Bug#503162: libc6: Doubt with nptl
On Thu, Oct 23, 2008 at 07:41:47PM +0700, Alexey Salmin wrote:
Freeing a variable...
if (err = pthread_rwlock_unlock(q-data-rwlock)) {
...and using it later is never a good idea. This is a problem in your
program, closing the bug.
? Can you please explain where am I freeing a variable? AFAIK
Quoting your code:
free(q);
if (err = pthread_rwlock_unlock(q-data-rwlock)) {
q is freed, and then use as an argument to pthread_rwlock_unlock().
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' [EMAIL PROTECTED] | [EMAIL PROTECTED]
`-people.debian.org/~aurel32 | www.aurel32.net
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503162: libc6: Doubt with nptl
Freeing a variable...
if (err = pthread_rwlock_unlock(q-data-rwlock)) {
...and using it later is never a good idea. This is a problem in your
program, closing the bug.
? Can you please explain where am I freeing a variable? AFAIK
pthread_rwlock_unlock function releases the lock but not delete it.
May be you thought about the pthread_rwlock_destroy?
http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlock_unlock.html
http://opengroup.org/onlinepubs/007908799/xsh/pthread_rwlockattr_destroy.html
The initial problem which caused this report is solved now, thats right. I
just
misunderstood the manual: The calling thread acquires the read lock if a
writer does not hold the lock and there are no writers blocked on the lock.
-
- If here really means if but not if and only if.
But I still don't understand why the SCHED_FIFO mechanism didn't work
the expected way.
Petr Salinger's note was right: May be scheduling of whole process have
to be set, may be it have to have enough priviledge to set SCHED_FIFO.
Or the manual does not reflect glibc reality.
1) I thought about the privileges to and tried to run the process with the
root privileges - it didn't help.
2) There is nothing in manuals about the whole process sheduling:
If the Thread Execution Scheduling option is supported, and the
(!) threads involved (!) in the lock are executing with the scheduling
policies SCHED_FIFO or SCHED_RR, the calling thread shall not
acquire the lock ...
3) If manual does not reflect the glibc reality then it should be fixed
as I understand.
Of course it's not a big deal but I just want to look into that.
Alexey Salmin
Processed: tagging 503182
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 503182 + pending Bug#503182: libc6-dev: rpcgen -a generate truncated Makefile file name There were no tags set. Tags added: pending End of message, 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#503202: libc6-dev: math_errhandling isn't defined anywhere
Package: libc6-dev Version: 2.3.6.ds1-13etch7 Severity: important Hi, math.h has the following in it: /* Bitmasks for the math_errhandling macro. */ # define MATH_ERRNO 1 /* errno set by math functions. */ # define MATH_ERREXCEPT 2 /* Exceptions raised by math functions. */ but no-where is math_errhandling actually defined! This breaks code wanting to check how domain errors in floating-point code are handled (amongst other things). Section 7.12.9 of C99 discusses MATH_ERRNO, MATH_ERREXCEPT, and math_errhandling. SuSv3 also requires math_errhandling to be present: http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html Regards, Matthew -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20-2-macpro-amd64 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages libc6-dev depends on: ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii linux-kernel-headers 2.6.18-7 Linux Kernel Headers for developme Versions of packages libc6-dev recommends: ii gcc [c-compiler] 4:4.1.1-15 The GNU C compiler ii gcc-3.4 [c-compiler] 3.4.6-5The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.1-21 The GNU C compiler -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503202: libc6-dev: math_errhandling isn't defined anywhere
reassign 503202 gcc-4.3 thanks Matthew Vernon a écrit : Package: libc6-dev Version: 2.3.6.ds1-13etch7 Severity: important Hi, math.h has the following in it: /* Bitmasks for the math_errhandling macro. */ # define MATH_ERRNO 1 /* errno set by math functions. */ # define MATH_ERREXCEPT 2 /* Exceptions raised by math functions. */ but no-where is math_errhandling actually defined! This breaks code wanting to check how domain errors in floating-point code are handled (amongst other things). Section 7.12.9 of C99 discusses MATH_ERRNO, MATH_ERREXCEPT, and math_errhandling. SuSv3 also requires math_errhandling to be present: http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html This is actually a compiler problem. See the footnotes on http://gcc.gnu.org/c99status.html . Reassigning the bug accordingly. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#503202: libc6-dev: math_errhandling isn't defined anywhere
Processing commands for [EMAIL PROTECTED]: reassign 503202 gcc-4.3 Bug#503202: libc6-dev: math_errhandling isn't defined anywhere Bug reassigned from package `libc6-dev' to `gcc-4.3'. 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]
Processed: tagging 503182
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 503182 + pending Bug#503182: libc6-dev: rpcgen -a generate truncated Makefile file name Tags were: pending Tags added: pending End of message, 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]
tzdata_2008e-1etch3_i386.changes INSTALLED into stable
Installing: tzdata_2008e-1etch3.diff.gz to pool/main/t/tzdata/tzdata_2008e-1etch3.diff.gz tzdata_2008e-1etch3.dsc to pool/main/t/tzdata/tzdata_2008e-1etch3.dsc tzdata_2008e-1etch3_all.deb to pool/main/t/tzdata/tzdata_2008e-1etch3_all.deb Override entries for your package: tzdata_2008e-1etch3.dsc - source libs tzdata_2008e-1etch3_all.deb - required libs Announcing to [EMAIL PROTECTED] Closing bugs: 502430 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#502430: marked as done (Argentina finally made up it's mind regarding DST)
Your message dated Thu, 23 Oct 2008 15:28:18 + with message-id [EMAIL PROTECTED] and subject line Bug#502430: fixed in tzdata 2008e-1etch3 has caused the Debian Bug report #502430, regarding Argentina finally made up it's mind regarding DST to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 502430: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502430 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems ---BeginMessage--- Package: tzdata Version: 2008h-1 Today the decree that establishes the DST period was finally published (the dates had already been announced, but the decree wasn't yet published). The link (only works for today) is: http://www.boletinoficial.gov.ar/Bora.Portal/CustomControls/PdfContent.aspx?fp=16102008pi=3pf=4s=0sec=01 It establishes the third Sunday in October and the third Sunday in March as the changing dates. So, I guess we can remove the argentina.diff patch (but something needs to be done about next year? Changing the max to 2009 instead of 2008 for the March line, would do it?) HOWEVER, there are several provinces that won't be going with this change. The ones that are certain are: Mendoza, San Luis, Catamarca, Salta. There's a chance that others won't change as well, but we can't predict the future, so we should go with what is certain. The following news article lists the provinces that won't change, for sure: http://www.lanacion.com.ar/nota.asp?nota_id=1059515 San Luis is already marked as fixed, and not following Arg. Salta doesn't exist as a specific regions, I don't know what to do about that one. So, apart from removing argentina.diff, we should add the following changes: Zone America/Argentina/Catamarca -4:23:08 - LMT 1894 Oct 31 (...) -3:00 Arg AR%sT 2008 Oct 18 -3:00 - ART Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31 (...) -3:00 Arg AR%sT 2008 Oct 18 -3:00 - ART (Real diff attached) -- Bessos, Maggie. --- southamerica 2008-10-08 09:46:17.0 -0300 +++ southamerica-modif 2008-10-16 10:06:06.0 -0300 @@ -428,7 +428,8 @@ -4:00 Arg AR%sT 2000 Mar 3 -3:00 - ART 2004 Jun 1 -4:00 - WART 2004 Jun 20 - -3:00 Arg AR%sT + -3:00 Arg AR%sT 2008 Oct 18 + -3:00 - ART # # Mendoza (MZ) Zone America/Argentina/Mendoza -4:35:16 - LMT 1894 Oct 31 @@ -445,7 +446,8 @@ -4:00 Arg AR%sT 2000 Mar 3 -3:00 - ART 2004 May 23 -4:00 - WART 2004 Sep 26 - -3:00 Arg AR%sT + -3:00 Arg AR%sT 2008 Oct 18 + -3:00 - ART # # San Luis (SL) Zone America/Argentina/San_Luis -4:25:24 - LMT 1894 Oct 31 ---End Message--- ---BeginMessage--- Source: tzdata Source-Version: 2008e-1etch3 We believe that the bug you reported is fixed in the latest version of tzdata, which is due to be installed in the Debian FTP archive: tzdata_2008e-1etch3.diff.gz to pool/main/t/tzdata/tzdata_2008e-1etch3.diff.gz tzdata_2008e-1etch3.dsc to pool/main/t/tzdata/tzdata_2008e-1etch3.dsc tzdata_2008e-1etch3_all.deb to pool/main/t/tzdata/tzdata_2008e-1etch3_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Margarita Manterola [EMAIL PROTECTED] (supplier of updated tzdata package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 17 Oct 2008 16:46:05 + Source: tzdata Binary: tzdata Architecture: source all Version: 2008e-1etch3 Distribution: stable Urgency: low Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Changed-By: Margarita Manterola [EMAIL PROTECTED] Description: tzdata - Time Zone and Daylight Saving Time Data Closes: 502430 Changes: tzdata (2008e-1etch3) stable; urgency=low . * Non-maintainer upload as requested by the maintainers. * Fix Argentina again, setting up the DST and adding exceptions for the provinces that don't change. Closes: #502430 Files: 60899e0f479fe0658c584e9fa4790cd4 883 libs required tzdata_2008e-1etch3.dsc cc78ddd81c6fa6b81d5c44dfde8b83b6 5191 libs required tzdata_2008e-1etch3.diff.gz 32da7ff0df213a0fd5dc9ce7d516d784 352998 libs required tzdata_2008e-1etch3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux)
Bug#503162: libc6: Doubt with nptl
Quoting your code:
free(q);
if (err = pthread_rwlock_unlock(q-data-rwlock)) {
q is freed, and then use as an argument to pthread_rwlock_unlock().
Wow. Sorry, usually I'm not SO stupid. But anyway this was not the problem
I was talking about. Moving free(q) down didn't affect anything.
Whats the problem with SCHED_FIFO I wonder?
PS Shit concentrating on thread and locks made me really blind!
Alexey Salmin
web site
Dear:Debian-glibc We can see you have a good site but you could use a significant increase in targeted web traffic. We can review your site for free and show you how you can improve this portion of your online business right away. Email us now at [EMAIL PROTECTED] and include your web site and how we can reach you. Sincerely, Lily Zey -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
