From bugmaster at FreeBSD.org Mon Jun 2 11:07:01 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 2 11:07:36 2008 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200806021107.m52B70go093320@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec f stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h 50 problems total. From bugmaster at FreeBSD.org Mon Jun 9 11:07:07 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 9 11:07:48 2008 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200806091107.m59B76oA070892@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec f stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim o stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h 50 problems total. From gavin at FreeBSD.org Wed Jun 11 13:27:47 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Jun 11 13:27:57 2008 Subject: standards/107561: [libc] [patch] [request] Missing SUS function tcgetsid() Message-ID: <200806111327.m5BDRk8c040308@freefall.freebsd.org> Synopsis: [libc] [patch] [request] Missing SUS function tcgetsid() State-Changed-From-To: open->patched State-Changed-By: gavin State-Changed-When: Wed Jun 11 13:26:06 UTC 2008 State-Changed-Why: Mark as patched, this is fixed in HEAD http://www.freebsd.org/cgi/query-pr.cgi?pr=107561 From bugmaster at FreeBSD.org Mon Jun 16 11:07:04 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 16 11:08:20 2008 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200806161107.m5GB7359036861@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec f stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h 50 problems total. From galu at agilenetworks.ro Mon Jun 16 17:20:01 2008 From: galu at agilenetworks.ro (Vlad GALU) Date: Mon Jun 16 17:20:06 2008 Subject: standards/124647: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) Message-ID: <200806161710.m5GHA8KW016720@www.freebsd.org> >Number: 124647 >Category: standards >Synopsis: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Jun 16 17:20:00 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Vlad GALU >Release: RELENG_7 >Organization: Agile Networks >Environment: FreeBSD joint.dudu.ro 7.0-STABLE FreeBSD 7.0-STABLE #1: Sat May 24 10:14:41 EEST 2008 root@joint.dudu.ro:/usr/src/sys/amd64/compile/JOINT amd64 >Description: The libstdc++ shipped with gcc 4.x supports some new associative containers, such as Patricia tries. The headers in /usr/include/c++/4.2/ext/pb_ds are incorrectly installed, as they have dependencies to other headers which are missing from the base system. >How-To-Repeat: Install FreeBSD 7.x :) >Fix: >Release-Note: >Audit-Trail: >Unformatted: From das at FreeBSD.ORG Mon Jun 16 19:35:33 2008 From: das at FreeBSD.ORG (David Schultz) Date: Mon Jun 16 19:35:36 2008 Subject: saving FPU state in setjmp/longjmp Message-ID: <20080616191308.GA25248@zim.MIT.EDU> Are setjmp/longjmp supposed to save and restore the FPU control word (rounding mode, exception masks, etc.)? They're specifically not supposed to touch the status word, and one would think that they shouldn't touch the control word either. From a pragmatic point of view, most apps don't touch the FP control word anyway, and the few that do are better off with fegetenv/fesetenv and friends. A brief survey of setjmp/longjmp implementations indicates: - freebsd/arm saves and restores the FPU status word, which is wrong. - freebsd/i386 and freebsd/amd64 save and restore the x87 control word but not the SSE control word, which is half wrong in one direction or the other. - freebsd/everything-else don't touch the FPU. - linux doesn't touch the FPU. - solaris doesn't touch the FPU. So the real question is whether to remove the part of setjmp and longjmp that fiddle with the x87 control word, or whether to extend these functions to also save and restore the SSE control word. The fact that SSE has been around for a while and nobody has noticed the breakage suggests that either change should have minimal impact on compatibility. From kan at FreeBSD.org Tue Jun 17 01:03:19 2008 From: kan at FreeBSD.org (kan@FreeBSD.org) Date: Tue Jun 17 01:03:20 2008 Subject: standards/124647: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) Message-ID: <200806170103.m5H13Ij4080288@freefall.freebsd.org> Synopsis: G++ in RELENG_7/HEAD doesn't include support for new containers in libstdc++(Patricia tries and others) State-Changed-From-To: open->patched State-Changed-By: kan State-Changed-When: Mon Jun 16 22:57:53 UTC 2008 State-Changed-Why: Patched in -current, will MFC shortly. Responsible-Changed-From-To: freebsd-standards->kan Responsible-Changed-By: kan Responsible-Changed-When: Mon Jun 16 22:57:53 UTC 2008 Responsible-Changed-Why: Patched in -current, will MFC shortly. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=124647 From dfilter at FreeBSD.org Tue Jun 17 08:10:06 2008 From: dfilter at FreeBSD.org (dfilter service) Date: Tue Jun 17 08:10:12 2008 Subject: standards/122051: commit references a PR Message-ID: <200806170810.m5H8A6ET081298@freefall.freebsd.org> The following reply was made to PR standards/122051; it has been noted by GNATS. From: dfilter@FreeBSD.org (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: standards/122051: commit references a PR Date: Tue, 17 Jun 2008 06:33:27 +0000 (UTC) davidxu 2008-06-17 06:26:29 UTC FreeBSD src repository Modified files: include Makefile unistd.h lib/libc/gen Makefile.inc Symbol.map exec.3 exec.c Added files: include spawn.h lib/libc/gen posix_spawn.c Log: SVN rev 179838 on 2008-06-17 06:26:29Z by davidxu Add POSIX routines called posix_spawn() and posix_spawnp(), which can be used as replacements for exec/fork in a lot of cases. This change also added execvpe() which allows environment variable PATH to be used for searching executable file, it is used for implementing posix_spawnp(). PR: standards/122051 Revision Changes Path 1.280 +1 -1 src/include/Makefile 1.1 +115 -0 src/include/spawn.h (new) 1.88 +1 -0 src/include/unistd.h 1.136 +2 -2 src/lib/libc/gen/Makefile.inc 1.11 +22 -0 src/lib/libc/gen/Symbol.map 1.27 +14 -3 src/lib/libc/gen/exec.3 1.24 +22 -9 src/lib/libc/gen/exec.c 1.1 +472 -0 src/lib/libc/gen/posix_spawn.c (new) _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From brde at optusnet.com.au Wed Jun 18 05:39:03 2008 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Jun 18 05:39:10 2008 Subject: saving FPU state in setjmp/longjmp In-Reply-To: <20080616191308.GA25248@zim.MIT.EDU> References: <20080616191308.GA25248@zim.MIT.EDU> Message-ID: <20080617225302.Y52409@delplex.bde.org> On Mon, 16 Jun 2008, David Schultz wrote: > Are setjmp/longjmp supposed to save and restore the FPU control > word (rounding mode, exception masks, etc.)? They're specifically > not supposed to touch the status word, and one would think that s/specifically not supposed to/unspecifically supposed to/ (C99 footnote 212 -- see below) > they shouldn't touch the control word either. From a pragmatic > point of view, most apps don't touch the FP control word anyway, > and the few that do are better off with fegetenv/fesetenv and friends. All my tests would fail if longjmp() didn't restore the control word. longjmp() from a signal handler can't possibly work unless the control word is restored, and my tests reduce to little more than testing this. longjmp() from a signal handler also needs to touch the status word to work -- it needs to at least clear the exception flags; on i386 it has used fninit to reset the entire FP status word for 15+ years since I fixed it, since this seemed to be the fastest way of resetting enough. More details: - long ago, the FP state in signal handlers was fairly broken -- it was the same as the preempted state except for special breakage (clearing) of the exception flags. My tests were written at this time. - longjump() from a signal handler thus restored the control word at the time of the setjmp(). The fninit in the i386 version of it prevents it keeping the (specially broken) status word at the time of the signal, so the exception flags are normally already clear. - Return from a signal handler (which gives undefined behaviour in most cases including all returns from SIGFPU handlers, especially in plain C99) gave reasonable behaviour -- both the control and (broken) status word at the time of the signal were kept. The broken status word was required for signal handlers to use floating point without having to clear the exception flags themself (but any useful use of FP in a signal handler caused undefined behaviour slightly before the signal handler returned; specifically, it could trap due to the settings of the preempted state, and it could corrupt the preempted state), and as a side effect this kept the cleared flags on return so that the preempted code could also continue using floating point without clearing the flags. - A copy of status word at the time of the exception was kept in the "exception status word" in the pcb and passed to signal handlers in in the signal context. gdb supported printing the copy in the pcb only. To restore and/or fix up the original state, the e.s.w. had to be merged with the active s.w. I don't know of any software that did this. - now, signal handlers get a private (reset) state. This fixes some of the bugs described above and helps implement the following new ones: - longjmp() from a signal handler has unchanged behaviour, but now it is even more necessary to restore the control word at the time of the setjmp() and to do something to not keep the current status word, since the current control and status word are private to the signal handler. If longjmp() didn't touch the FP state, then the only way to get back to the preempted state after the longjmp() would be for the signal handler to restore the preempted state before the longjmp(). Signal handlers would have a hard time supporting this unportable complication, epsecially if they are not SIGFPE handers. - Return from a signal handler now restores the preempted FP state, modulo the breakage of the exception flags. When signal handlers started getting a reset state, I thought that the exception flags didn't need to be broken and changed npxtrap() to not break them, but this broke my tests of returning from SIGFPE handlers -- the tests just set a flag and return, but this no longer works since nothing including the tests clears the exception flags. (The tests also change the control word so that SIGFPE's for FP exceptions actually occur if the relevant exception flags are set; then if they remain set the fault repeats like an integer divide-by-0 SIGFPE.) - The exception status word and gdb's support for it have been lost (except in cvs history). Before clearing the flags, the flags are encoded in a number in the sigcontext. Then some info is lost when the flags are cleared. > A brief survey of setjmp/longjmp implementations indicates: > - freebsd/arm saves and restores the FPU status word, which is wrong. I think this is least broken. On i386, it is just an optimization to not save/restore the status word. Save/restore of it at least keeps any exception flags that are set at the time of the setjmp(). > - freebsd/i386 and freebsd/amd64 save and restore the x87 control word > but not the SSE control word, which is half wrong in one direction or > the other. These also reset the status word. This is mainly an optimization. When they were written, there was no support for FP state in C, so setjmp()/longjmp() only had to preserve as much FP state as a normal function. > - freebsd/everything-else don't touch the FPU. > - linux doesn't touch the FPU. > - solaris doesn't touch the FPU. All of these are broken. C99 unspecifically requires the arm behaviour: - in n869.txt, it requires restoring the "calling environment of the abstract machine" at the time of the setjmp(). - in n1124.pdf footnote 212, it specifically says that FP status flags are part of the calling env. Footnotes are not normative, and it doesn't seem to say anything specifically about the control word, but clearly the calling environment is intended to include all FP state. I must have interpreted the corresponding requirement in C90 loosely to justify not preserving any FP status when I fixed the i386 version to restore the control word. The abstract machine in C90 required little or nothing of FP. > So the real question is whether to remove the part of setjmp and > longjmp that fiddle with the x87 control word, or whether to > extend these functions to also save and restore the SSE control > word. The fact that SSE has been around for a while and nobody has > noticed the breakage suggests that either change should have > minimal impact on compatibility. According to C99, all FP state must be preserved, but we can still avoid preserving data registers and some perhaps other details that aren't part of the abstract machine. Breakage of the exception flags is rarely observed since no one uses these :-). Breakage of SIGFPE handlers is even more rarely observed since no one unmasks FP exceptions :-), and signals for FP exceptions give undefined behaviour anyway. The most interesting case is for longjmp() from a signal handler for non-FP signal. Some cases should work, without the signal handler knowing anything about FP. When the signal occurs, the FP state may be arbitrarily exotic, and it must become normal when longjmp() returns. The current i386 implementation gives this except it messes up the C99 exception flags. Bruce From kris at FreeBSD.org Sat Jun 21 13:16:13 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Sat Jun 21 13:16:16 2008 Subject: execvpe port breakage In-Reply-To: <485B884A.70006@freebsd.org> References: <485B7FFC.4040509@FreeBSD.org> <485B884A.70006@freebsd.org> Message-ID: <485CFF1B.2080500@FreeBSD.org> David Xu wrote: > Kris Kennaway wrote: >> http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.2008062001/deco-3.9_3.log >> >> >> Can someone please take a look? >> >> Kris >> > > Looks like the application defined its own version of execvpe() ? > I think we should change name execvpe in our header file to something > else to avoid conflict. > > David Xu > > There are a few others too: ./deco-3.9_3.log ./gdc-0.24_3.log ./ghc-6.8.2_1.log ./hugs98-200609_2.log ./jdk-1.6.0.3p4_2.log Also sysutils/screen. We could either patch these, try to alter the prototype of our execvpe to match, or rename/hide our version. I don't know if there is a standards-based argument. Kris From syl at ash.kaz.appi.keio.ac.jp Sat Jun 21 23:00:14 2008 From: syl at ash.kaz.appi.keio.ac.jp (Tomohisa Tanaka) Date: Sat Jun 21 23:00:18 2008 Subject: standards/124860: flockfile(3) doesn't work when the memory has been exhausted. Message-ID: <200806212303.m5LN3TR6074703@ash.kaz.appi.keio.ac.jp> >Number: 124860 >Category: standards >Synopsis: flockfile(3) doesn't work when the memory has been exhausted. >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-standards >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sat Jun 21 23:00:13 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Tomohisa Tanaka >Release: FreeBSD 6.3-RELEASE i386 >Organization: >Environment: System: FreeBSD freebsd.localdomain 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 04:18:52 UTC 2008 root@dessler.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 >Description: When the flockfile(3) acquires a lock, and the specified stream has never locked, and the memory has been exhausted, flockfile(3) returns without the stream locked. The flockfile(3) calls _pthread_mutex_lock() according to the file /usr/src/lib/libc/stdio/_flock_stub.c, as follows. /usr/src/lib/libc/stdio/_flock_stub.c: 69 #define _lock _extra ... 83 _pthread_mutex_lock(&fp->_lock->fl_mutex); The _pthread_mutex_lock() does never fail if fp->_extra->fl_mutex has already been dynamically initialized. However, if fp->_extra->fl_mutex has been statically initialized, the _pthread_mutex_lock() tries to perform the dynamic initialization of it by calling the pthread_mutex_init(3), as follows. /usr/src/lib/libpthread/thread/thr_mutex.c: 302 static int 303 init_static_private(struct pthread *thread, pthread_mutex_t *mutex) 304 { ... 310 ret = pthread_mutex_init(mutex, &static_mattr); ... 317 } ... 849 int 850 _pthread_mutex_lock(pthread_mutex_t *m) 851 { ... 866 else if ((*m != NULL) || 867 ((ret = init_static_private(curthread, m)) == 0)) 868 ret = mutex_lock_common(curthread, m, NULL); ... 871 } When the memory has been exhausted, the pthread_mutex_init(3) returns ENOMEM. All mutexes of the stdio stream are statically initialized, according to the file /usr/src/lib/libc/stdio/findfp.c. >How-To-Repeat: % cat test.c #include #include #include #include #include static pthread_barrier_t barrier; static FILE *fp; static void * run(void *arg) { pthread_barrier_wait(&barrier); flockfile(fp); /* [1] */ return NULL; } int main(void) { pthread_t thread; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; void *p; size_t k; if (pthread_barrier_init(&barrier, NULL, 2) != 0) err(1, "pthread_barrier_init"); if (pthread_create(&thread, NULL, run, NULL) != 0) err(1, "pthread_create"); if ((fp = fopen("log", "w")) == NULL) err(1, "log"); #if 1 for (k = 1; k < 64; ++k) { while ((p = malloc(k)) != NULL) ; } /* * Now, we are in a special situation where the memory has been * extremely exhausted. Here, 'mutex' has not initialized with * pthread_mutex_init(3), so pthread_mutex_lock(3) as follows will * try to initialize "mutex" using pthread_mutex_init(3) internally. * However, malloc(3) within the pthread_mutex_init(3) returns NULL, * and then pthread_mutex_lock(3) fails and returns ENOMEM. */ if ((errno = pthread_mutex_lock(&mutex)) != 0) { warn("pthread_mutex_lock"); } #endif flockfile(fp); /* [2] */ /* * Here, this main thread does NOT have the lock of "fp", because * pthread_mutex_lock(3) within flockfile(3) at [2] has failed. We * must remember "fp->_extra->fl_mutex" has not been initialized by * pthread_mutex_init(3) as well as "mutex". */ pthread_barrier_wait(&barrier); /* * Another thread will call flockfile(3) at [1], but it returns * immediately. No thread can get the lock of 'fp' in this * situation. If we comment out from "#if 1" to "#endif", a * deadlock occurs. */ pthread_join(thread, NULL); return 0; } % cat test.sh #!/bin/sh ulimit -v 10000 ./a.out % gcc -pthread test.c % sh test.sh a.out: pthread_mutex_lock: Cannot allocate memory % >Fix: I think that the function __sfp() of /usr/src/lib/libc/stdio/findfp.c must perform the dynamic initialization of fp->_extra->fl_mutex, if it has been only statically initialized. And if it failed, __sfp() must return NULL. >Release-Note: >Audit-Trail: >Unformatted: From ru at freebsd.org Sat Jun 21 23:24:41 2008 From: ru at freebsd.org (Ruslan Ermilov) Date: Sat Jun 21 23:24:45 2008 Subject: execvpe port breakage In-Reply-To: <485CFF1B.2080500@FreeBSD.org> References: <485B7FFC.4040509@FreeBSD.org> <485B884A.70006@freebsd.org> <485CFF1B.2080500@FreeBSD.org> Message-ID: <20080621225850.GA21194@team.vega.ru> On Sat, Jun 21, 2008 at 03:16:11PM +0200, Kris Kennaway wrote: > David Xu wrote: > > Kris Kennaway wrote: > >> http://pointyhat.freebsd.org/errorlogs/amd64-errorlogs/e.8.2008062001/deco-3.9_3.log > >> > >> > >> Can someone please take a look? > >> > >> Kris > >> > > > > Looks like the application defined its own version of execvpe() ? > > I think we should change name execvpe in our header file to something > > else to avoid conflict. > > > > David Xu > > > > > > There are a few others too: > > ./deco-3.9_3.log > ./gdc-0.24_3.log > ./ghc-6.8.2_1.log > ./hugs98-200609_2.log > ./jdk-1.6.0.3p4_2.log > > Also sysutils/screen. > > We could either patch these, try to alter the prototype of our execvpe > to match, or rename/hide our version. I don't know if there is a > standards-based argument. > I've fixed the deco port to detect if the system has execvpe() implementation. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From bugmaster at FreeBSD.org Mon Jun 23 11:07:03 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 23 11:07:40 2008 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200806231107.m5NB72ZI065111@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec f stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards [patch] grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/124860 standards flockfile(3) doesn't work when the memory has been exh 51 problems total. From gavin at FreeBSD.org Wed Jun 25 15:59:56 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Wed Jun 25 15:59:59 2008 Subject: standards/25777: [kernel] [patch] atime not updated on exec Message-ID: <200806251559.m5PFxttn085906@freefall.freebsd.org> Synopsis: [kernel] [patch] atime not updated on exec State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Wed Jun 25 15:59:36 UTC 2008 State-Changed-Why: The requested feedback was provided in August 2002 http://www.freebsd.org/cgi/query-pr.cgi?pr=25777 From bugmaster at FreeBSD.org Mon Jun 30 11:07:05 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Jun 30 11:07:30 2008 Subject: Current problem reports assigned to freebsd-standards@FreeBSD.org Message-ID: <200806301107.m5UB745R095895@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/25542 standards sh(1) null char in quoted string o stand/54410 standards one-true-awk not POSIX compliant (no extended REs) o stand/82654 standards C99 long double math functions are missing o stand/94729 standards [libc] fcntl() throws undocumented ENOTTY 4 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s bin/14925 standards getsubopt isn't poisonous enough o stand/21519 standards sys/dir.h should be deprecated some more o bin/24390 standards ln(1) Replacing old dir-symlinks when using /bin/ln s stand/24590 standards timezone function not compatible witn Single Unix Spec o stand/25777 standards [kernel] [patch] atime not updated on exec a docs/26003 standards getgroups(2) lists NGROUPS_MAX but not syslimits.h o kern/27835 standards [libc] execve() doesn't conform to execve(2) spec in s s stand/36076 standards Implementation of POSIX fuser command o stand/39256 standards snprintf/vsnprintf aren't POSIX-conformant for strings p stand/41576 standards POSIX compliance of ln(1) o stand/44425 standards getcwd() succeeds even if current dir has perm 000. o stand/46119 standards Priority problems for SCHED_OTHER using pthreads o stand/54833 standards [pcvt] more pcvt deficits o stand/54839 standards [pcvt] pcvt deficits p stand/55112 standards glob.h, glob_t's gl_pathc should be "size_t", not "int o stand/56476 standards cd9660 unicode support simple hack o stand/58676 standards [patch] grantpt(3) alters storage used by ptsname(3) s stand/62858 standards malloc(0) not C99 compliant s kern/64875 standards [libc] [patch] [request] add a system call: fdatasync( o stand/66357 standards make POSIX conformance problem ('sh -e' & '+' command- o stand/66531 standards [libc] [patch] _gettemp uses a far smaller set of file o stand/70813 standards [PATCH] ls(1) not Posix compliant o stand/72006 standards floating point formating in non-C locales o stand/79056 standards [feature request] [atch] regex(3) regression tests a stand/80293 standards sysconf() does not support well-defined unistd values o stand/81287 standards [PATCH]: fingerd(8) might send a line not ending in CR o stand/83845 standards [libm] [patch] add log2() and log2f() support for libm a stand/86484 standards [PATCH] mkfifo(1) uses wrong permissions o stand/92360 standards [headers] [patch] Missing TAB3 in kernel headers o stand/92362 standards [headers] [patch] Missing SIGPOLL in kernel headers o kern/93705 standards [headers] [patch] ENODATA and EGREGIOUS (for glibc com o stand/96016 standards [headers] clock_getres et al should be in o stand/96236 standards [PATCH] [POSIX] sed.1 incorrectly describes a function p stand/99517 standards Missing SIGRTMIN and SIGRTMAX signals o stand/99960 standards [Patch] make(1): Add -p flag o stand/100017 standards [Patch] Add fuser(1) functionality to fstat(1) o stand/104743 standards [headers] [patch] Wrong values for _POSIX_ minimal lim p stand/107561 standards [libc] [patch] [request] Missing SUS function tcgetsid o kern/114578 standards [libc] wide character printing using swprintf(dst, n, o stand/116081 standards make does not work with the directive sinclude o stand/116221 standards [kernel] [patch] [request] SUS issue -- FreeBSD has no o bin/116413 standards incorrect getconf(1) handling of unsigned constants gi o stand/116826 standards [PATCH] sh support for POSIX character classes o stand/118047 standards SUGGESTION: /etc/printcap vs mergemaster o stand/119804 standards [timedef] [patch] Invalid (long)date format in pl_PL.I o stand/120947 standards xsm ignores system.xsm and .xsmstartup o stand/121568 standards [patch] ln(1): wrong "ln -s" behaviour o stand/121921 standards [patch] Add leap second support to at(1), atrun(8) o stand/122051 standards Add posix_spawn(3) o stand/123688 standards POSIX standard changes in unistd.h and grp.h o stand/124860 standards flockfile(3) doesn't work when the memory has been exh 51 problems total. From gavin at FreeBSD.org Mon Jun 30 11:11:38 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Mon Jun 30 11:11:42 2008 Subject: standards/116477: rm(1): rm behaves unexpectedly when using -r and relative paths Message-ID: <200806301111.m5UBBNeR098945@freefall.freebsd.org> Synopsis: rm(1): rm behaves unexpectedly when using -r and relative paths State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Mon Jun 30 11:06:18 UTC 2008 State-Changed-Why: bde@ still feels that our rm(1) doesn't follow POSIX: http://docs.FreeBSD.org/cgi/mid.cgi?20080628113326.Y89027 Responsible-Changed-From-To: freebsd-bugs->freebsd-standards Responsible-Changed-By: gavin Responsible-Changed-When: Mon Jun 30 11:06:18 UTC 2008 Responsible-Changed-Why: Over to -standards for consideration http://www.freebsd.org/cgi/query-pr.cgi?pr=116477 From kris at FreeBSD.org Mon Jun 30 17:51:49 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 30 17:51:51 2008 Subject: mkdir -p through a dangling symlink Message-ID: <48691D31.9010202@FreeBSD.org> Suppose you do this: gohan20# ln -sf /y/portbuild /var/portbuild gohan20# mkdir -p /var/portbuild/scripts mkdir: /var/portbuild: No such file or directory (because /y/portbuild doesn't exist yet). Is this the correct behaviour, or should mkdir -p be creating /var/portbuild/ before failing? Kris From wollman at csail.mit.edu Mon Jun 30 18:41:07 2008 From: wollman at csail.mit.edu (Garrett Wollman) Date: Mon Jun 30 18:41:10 2008 Subject: mkdir -p through a dangling symlink In-Reply-To: <48691D31.9010202@FreeBSD.org> References: <48691D31.9010202@FreeBSD.org> Message-ID: <18537.9084.554477.556052@khavrinen.csail.mit.edu> < said: > Suppose you do this: > gohan20# ln -sf /y/portbuild /var/portbuild > gohan20# mkdir -p /var/portbuild/scripts > mkdir: /var/portbuild: No such file or directory > (because /y/portbuild doesn't exist yet). > Is this the correct behaviour, or should mkdir -p be creating > /var/portbuild/ before failing? This is the correct behavior. The semantics of the -p option are defined lexically on the arguments provided, not on the contents of the filesystem. See XCU page 635 lines 24488ff: # For each dir operand that does not name an existing directory, # effects equivalent to those caused by the following command shall # occur: # mkdir -p -m $(umask -S),u+wx $(dirname dir) && # mkdir [-m mode] dir # where the -m mode option represents that option supplied to the original # invocation of mkdir, if any. (References are for the 2001 final published standard.) -GAWollman From kris at FreeBSD.org Mon Jun 30 18:58:17 2008 From: kris at FreeBSD.org (Kris Kennaway) Date: Mon Jun 30 18:58:19 2008 Subject: mkdir -p through a dangling symlink In-Reply-To: <18537.9084.554477.556052@khavrinen.csail.mit.edu> References: <48691D31.9010202@FreeBSD.org> <18537.9084.554477.556052@khavrinen.csail.mit.edu> Message-ID: <48692CC5.4030308@FreeBSD.org> Garrett Wollman wrote: > < said: > >> Suppose you do this: >> gohan20# ln -sf /y/portbuild /var/portbuild >> gohan20# mkdir -p /var/portbuild/scripts >> mkdir: /var/portbuild: No such file or directory > >> (because /y/portbuild doesn't exist yet). > >> Is this the correct behaviour, or should mkdir -p be creating >> /var/portbuild/ before failing? > > This is the correct behavior. The semantics of the -p option are > defined lexically on the arguments provided, not on the contents of > the filesystem. See XCU page 635 lines 24488ff: > > # For each dir operand that does not name an existing directory, > # effects equivalent to those caused by the following command shall > # occur: > > # mkdir -p -m $(umask -S),u+wx $(dirname dir) && > # mkdir [-m mode] dir > > # where the -m mode option represents that option supplied to the original > # invocation of mkdir, if any. > > (References are for the 2001 final published standard.) Thanks! Kris