kern/155303: Mounted firewire disks prevent reboot
>Number: 155303 >Category: kern >Synopsis: Mounted firewire disks prevent reboot >Confidential: no >Severity: non-critical >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 06 08:50:10 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Antti Louko >Release:8.2-RELEASE >Organization: >Environment: FreeBSD spr1.z.fi 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Wed Mar 2 22:15:53 UTC 2011 r...@alo97-r82.louko.com:/usr/src/sys/amd64/compile/ALOIPF5 amd64 >Description: Having mounted firewire disks prevent programmable reboot. System shuts down and console shows the last "uptime" message but newer resets or reboots. Reset key or power cycling is necessary to reboot. In this case, system has UFS basic partitions in /dev/ad* disks and two ZFS pools, one totally in ad* disks and another in da* disks which are firewire-connected. Without firewire disks mounted, reboot succeedes but with them it hangs. If I remember correctly, this has appeared also with UFS-mounted firewire disks. >How-To-Repeat: Make a zpool on fw disk or disks. Mount it. Try to reboot. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/155306: [ERROR] no work ports/multimedia/openshot
>Number: 155306 >Category: misc >Synopsis: [ERROR] no work ports/multimedia/openshot >Confidential: no >Severity: non-critical >Priority: low >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 06 09:50:04 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Andrei Lavreniyuk >Release:FreeBSD 8.2-STABLE >Organization: Technica-03, Inc. >Environment: FreeBSD datacenter.technica-03.local 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Mar 4 10:44:47 EET 2011 root@datacenter.technica-03.local:/usr/obj/usr/src/sys/SMP64 amd64 >Description: > openshot OpenShot (version 1.3.0) Process no longer exists: 26089. Creating new pid lock file. --- Error: OpenShot has not been installed in the Python path. (Both the site-packages and /usr/share/openshot folders were checked) Use the following command to install OpenShot: $ sudo python setup.py install >How-To-Repeat: # cd /usr/ports/multimedia/openshot # make install clean # rehash % openshot >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: ports/155306: [ERROR] multimedia/openshot doesn't work
Old Synopsis: [ERROR] no work ports/multimedia/openshot New Synopsis: [ERROR] multimedia/openshot doesn't work Responsible-Changed-From-To: freebsd-bugs->freebsd-ports-bugs Responsible-Changed-By: brucec Responsible-Changed-When: Sun Mar 6 09:58:58 UTC 2011 Responsible-Changed-Why: Ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=155306 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
gnu/155308: [PATCH] gcc: backport geode and core2 march options
>Number: 155308
>Category: gnu
>Synopsis: [PATCH] gcc: backport geode and core2 march options
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Mar 06 10:50:08 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Martin Matuska
>Release:FreeBSD 9-CURRENT amd64
>Organization:
>Environment:
>Description:
Backport CPU types AMD geode and core2 to gcc.
These options are supported in all later GCC's, the change is
GPLv2-licensed. I recommend backporting these options to contrib/gcc
and adding the new flags to share/mk/bsd.cpu.mk
The gcc-4.3 branch SVN revisions are 118090, 118973 and 120846, are fully
compatible with our code and apply almost completely cleanly (the only
reject is one line where bswap32/64 have been added).
The SSSE3 instruction set is of course not supported, but this is the same
as in gcc-4.3 r118973 (it was added to gcc-4.3 later than core2/geode
support). The latest binutils import in base of head supports SSSE3,
so the SSSE3 support may be imported at a later point.
References:
http://gcc.gnu.org/viewcvs?view=revision&revision=118090
http://gcc.gnu.org/viewcvs?view=revision&revision=118973
http://gcc.gnu.org/viewcvs?view=revision&revision=120846
>How-To-Repeat:
>Fix:
Index: contrib/gcc/doc/invoke.texi
===
--- contrib/gcc/doc/invoke.texi (revision 219330)
+++ contrib/gcc/doc/invoke.texi (working copy)
@@ -9369,6 +9369,9 @@
@item nocona
Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE,
SSE2 and SSE3 instruction set support.
+@item core2
+Intel Core2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3 and SSSE3
+instruction set support.
@item k6
AMD K6 CPU with MMX instruction set support.
@item k6-2, k6-3
@@ -9396,6 +9399,8 @@
@item c3-2
Via C3-2 CPU with MMX and SSE instruction set support. (No scheduling is
implemented for this chip.)
+@item geode
+Embedded AMD CPU with MMX and 3dNOW! instruction set support.
@end table
While picking a specific @var{cpu-type} will schedule things appropriately
Index: contrib/gcc/config.gcc
===
--- contrib/gcc/config.gcc (revision 219330)
+++ contrib/gcc/config.gcc (working copy)
@@ -1207,14 +1207,14 @@
# FIXME: -m64 for i[34567]86-*-* should be allowed just
# like -m32 for x86_64-*-*.
case X"${with_cpu}" in
- Xgeneric|Xnocona|Xx86-64|Xk8|Xopteron|Xathlon64|Xathlon-fx)
+
Xgeneric|Xcore2|Xnocona|Xx86-64|Xk8|Xopteron|Xathlon64|Xathlon-fx)
;;
X)
with_cpu=generic
;;
*)
echo "Unsupported CPU used in --with-cpu=$with_cpu,
supported values:" 1>&2
- echo "generic nocona x86-64 k8 opteron athlon64
athlon-fx" 1>&2
+ echo "generic core2 nocona x86-64 k8 opteron athlon64
athlon-fx" 1>&2
exit 1
;;
esac
@@ -2537,6 +2537,9 @@
nocona-*)
with_cpu=nocona
;;
+ core2-*)
+ with_cpu=core2
+ ;;
pentium_m-*)
with_cpu=pentium-m
;;
@@ -2556,6 +2559,9 @@
nocona-*)
with_cpu=nocona
;;
+ core2-*)
+ with_cpu=core2
+ ;;
*)
with_cpu=generic
;;
@@ -2787,7 +2793,7 @@
esac
# OK
;;
- "" | k8 | opteron | athlon64 | athlon-fx | nocona |
generic)
+ "" | k8 | opteron | athlon64 | athlon-fx | nocona |
core2 | generic)
# OK
;;
*)
Index: contrib/gcc/config/i386/i386.h
===
--- contrib/gcc/config/i386/i386.h (revision 219330)
+++ contrib/gcc/config/i386/i386.h (working copy)
@@ -130,12 +130,14 @@
#define TARGET_486 (ix86_tune == PROCESSOR_I486)
#define TARGET_PENTIUM (ix86_tune == PROCESSOR_PENTIUM)
#define TARGET_PENTIUMPRO (ix86_tune == PROCESSOR_PENTIUMPRO)
+#define TARGET_GEODE (ix86_tune == PROCESSOR_GEODE)
#define TARGET_K6 (ix86_tune == PROCESSOR_K6)
#define TARGET_ATHLON (ix86_tune == PROCESSOR_ATHLON)
#define TARGET_PENTIUM4 (ix86_tune == PROCESSOR_PENTIUM4)
#define TARGET_K8 (ix86_tune == PROCESSOR_K8)
#define TARGET_ATHLON_K8 (TARGET_K8 || TARGET_ATHLON)
#define TARGET_NOCONA (ix86_tune == PROCESSOR_NOCONA)
+#define TARGET_CORE2 (ix86_tune == PROCESSOR_CORE2)
#define TARGET_GENERIC32 (ix86_tune == P
gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()
>Number: 155309
>Category: gnu
>Synopsis: [PATCH] gcc: backport bswap32() and bswap64()
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Sun Mar 06 11:00:22 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Martin Matuska
>Release:FreeBSD 9-CURRENT amd64
>Organization:
>Environment:
>Description:
In many ports, we have to deal with patching the missing bswap32()
and bswap64() functions.
The gcc-4.3 branch SVN revision is 118361, is GPLv2-licensed,
applies cleanly and is fully compatible with our code.
References:
http://gcc.gnu.org/viewcvs?view=revision&revision=118361
>How-To-Repeat:
>Fix:
Index: contrib/gcc/doc/extend.texi
===
--- contrib/gcc/doc/extend.texi (revision 219330)
+++ contrib/gcc/doc/extend.texi (working copy)
@@ -6147,7 +6147,17 @@
are @code{long double}.
@end deftypefn
+@deftypefn {Built-in Function} int32_t __builtin_bswap32 (int32_t x)
+Returns @var{x} with the order of the bytes reversed; for example,
+@code{0xaabbccdd} becomes @code{0xddccbbaa}. Byte here always means
+exactly 8 bits.
+@end deftypefn
+@deftypefn {Built-in Function} int64_t __builtin_bswap64 (int64_t x)
+Similar to @code{__builtin_bswap32}, except the argument and return types
+are 64-bit.
+@end deftypefn
+
@node Target Builtins
@section Built-in Functions Specific to Particular Target Machines
Index: contrib/gcc/doc/libgcc.texi
===
--- contrib/gcc/doc/libgcc.texi (revision 219330)
+++ contrib/gcc/doc/libgcc.texi (working copy)
@@ -212,6 +212,11 @@
These functions return the number of bits set in @var{a}.
@end deftypefn
+@deftypefn {Runtime Function} int32_t __bswapsi2 (int32_t @var{a})
+@deftypefnx {Runtime Function} int64_t __bswapdi2 (int64_t @var{a})
+These functions return the @var{a} byteswapped.
+@end deftypefn
+
@node Soft float library routines
@section Routines for floating point emulation
@cindex soft float library
@@ -728,4 +733,3 @@
@deftypefn {Runtime Function} void __clear_cache (char *@var{beg}, char
*@var{end})
This function clears the instruction cache between @var{beg} and @var{end}.
@end deftypefn
-
Index: contrib/gcc/doc/rtl.texi
===
--- contrib/gcc/doc/rtl.texi(revision 219330)
+++ contrib/gcc/doc/rtl.texi(working copy)
@@ -2084,6 +2084,11 @@
Represents the number of 1-bits modulo 2 in @var{x}, represented as an
integer of mode @var{m}. The mode of @var{x} will usually be an integer
mode.
+
+@findex bswap
+@item (bswap:@var{m} @var{x})
+Represents the value @var{x} with the order of bytes reversed, carried out
+in mode @var{m}, which must be a fixed-point machine mode.
@end table
@node Comparisons
Index: contrib/gcc/optabs.c
===
--- contrib/gcc/optabs.c(revision 219330)
+++ contrib/gcc/optabs.c(working copy)
@@ -2591,6 +2591,10 @@
goto try_libcall;
}
+ /* We can't widen a bswap. */
+ if (unoptab == bswap_optab)
+goto try_libcall;
+
if (CLASS_HAS_WIDER_MODES_P (class))
for (wider_mode = GET_MODE_WIDER_MODE (mode);
wider_mode != VOIDmode;
@@ -5253,6 +5257,7 @@
absv_optab = init_optabv (ABS);
addcc_optab = init_optab (UNKNOWN);
one_cmpl_optab = init_optab (NOT);
+ bswap_optab = init_optab (BSWAP);
ffs_optab = init_optab (FFS);
clz_optab = init_optab (CLZ);
ctz_optab = init_optab (CTZ);
@@ -5456,6 +5461,11 @@
init_interclass_conv_libfuncs (trunc_optab, "trunc", MODE_FLOAT,
MODE_DECIMAL_FLOAT);
init_interclass_conv_libfuncs (trunc_optab, "trunc", MODE_DECIMAL_FLOAT,
MODE_FLOAT);
+ /* Explicitly initialize the bswap libfuncs since we need them to be
+ valid for things other than word_mode. */
+ set_optab_libfunc (bswap_optab, SImode, "__bswapsi2");
+ set_optab_libfunc (bswap_optab, DImode, "__bswapdi2");
+
/* Use cabs for double complex abs, since systems generally have cabs.
Don't define any libcall for float complex, so that cabs will be used. */
if (complex_double_type_node)
Index: contrib/gcc/optabs.h
===
--- contrib/gcc/optabs.h(revision 219330)
+++ contrib/gcc/optabs.h(working copy)
@@ -146,6 +146,8 @@
/* Abs value */
OTI_abs,
OTI_absv,
+ /* Byteswap */
+ OTI_bswap,
/* Bitwise not */
OTI_one_cmpl,
/* Bit scanning and counting */
@@ -315,6 +317,7 @@
#define abs_optab (optab_table[OTI_abs])
#define absv_optab (optab_table[OTI_absv])
#define one_cmpl_optab (optab_table[OTI_one_cmpl])
+#define bswap_optab (optab_table[OTI_bswap])
#define ffs_optab (optab_table[OTI_ffs])
Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()
On Sun, 6 Mar 2011, Martin Matuska wrote: Description: In many ports, we have to deal with patching the missing bswap32() and bswap64() functions. Er, we have these in endian.h. The gcc-4.3 branch SVN revision is 118361, is GPLv2-licensed, applies cleanly and is fully compatible with our code. However, gcc doesn't know how to turn a C expression for bswap*() into the bswap instruction. clang does. Does this patch fix that? Using the C expression in all cases allows cleaning endian.h files, except possibly on other arches that still need asm. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64()
The following reply was made to PR gnu/155309; it has been noted by GNATS. From: Bruce Evans To: Martin Matuska Cc: freebsd-gnats-sub...@freebsd.org, freebsd-bugs@FreeBSD.org Subject: Re: gnu/155309: [PATCH] gcc: backport bswap32() and bswap64() Date: Sun, 6 Mar 2011 22:28:19 +1100 (EST) On Sun, 6 Mar 2011, Martin Matuska wrote: >> Description: > In many ports, we have to deal with patching the missing bswap32() > and bswap64() functions. Er, we have these in endian.h. > The gcc-4.3 branch SVN revision is 118361, is GPLv2-licensed, > applies cleanly and is fully compatible with our code. However, gcc doesn't know how to turn a C expression for bswap*() into the bswap instruction. clang does. Does this patch fix that? Using the C expression in all cases allows cleaning endian.h files, except possibly on other arches that still need asm. Bruce ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/155319: Immediate kernel crash when starting X on 9.0-CURRENT with r400/r500 GPU
>Number: 155319 >Category: kern >Synopsis: Immediate kernel crash when starting X on 9.0-CURRENT with >r400/r500 GPU >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 06 19:20:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Adam Kirchhoff >Release:9.0-CURRENT >Organization: None >Environment: FreeBSD sorrow.ashke.com 9.0-CURRENT FreeBSD 9.0-CURRENT #3: Tue Feb 22 04:53:58 EST 2011 root@:/usr/obj/usr/src/sys/SORROW amd64 >Description: As soon as I start X with either an X850 or X1900 in this particular machine running 9.0-CURRENT, I get a kernel crash. There is no kernel debug prompt, and no dump created. The only output on the serial port is below. A radeon HD4850 works fine, leading me to believe that this is specific to the r300-r500 DRM code. If I configure Xorg to disable glx and dri, X starts up. Fatal trap 28: machine check trap while in kernel mode Fatal trap 28: machine check trap while in kernel mode cpuid = 3; cpuid = 2; apic id = 03 apic id = 02 instruction pointer = 0x20:0x809e6346 instruction pointer = 0x20:0x809e6346 stack pointer = 0x28:0xff833ad0 stack pointer = 0x28:0xff838ad0 frame pointer = 0x28:0xff833ae0 frame pointer = 0x28:0xff838ae0 code segment= base 0x0, limit 0xf, type 0x1b code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= processor eflags = interrupt enabled, interrupt enabled, IOPL = 0 IOPL = 0 current process = current process = 11 (idle: cpu3) 1 Fatal trap 28: machine check trap while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x20:0x809f5aa2 stack pointer = 0x28:0xff81bdf0 frame pointer = 0x28:0xff81be20 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= IOPL = 0 current process = 11 (idle: cpu2) >How-To-Repeat: Install 9.0-CURRENT on a machine with a radeon r4xx/r5xx GPU. Start X. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
misc/155320: cpufreq/powerd + xorg-7.5.1 + xf86-video-intel-2.7.1_4 leads to freeze
>Number: 155320 >Category: misc >Synopsis: cpufreq/powerd + xorg-7.5.1 + xf86-video-intel-2.7.1_4 leads >to freeze >Confidential: no >Severity: serious >Priority: medium >Responsible:freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Mar 06 19:30:09 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Martin Birgmeier >Release:7.4.0 i386 >Organization: MBi at home >Environment: FreeBSD a.xyzzy 7.4-RELEASE FreeBSD 7.4-RELEASE #1: Sun Feb 20 20:18:26 CET 2011 root@v901.xyzzy:/.../hal/z/OBJ/FreeBSD/i386/RELENG_7_4_0_RELEASE/src/sys/XYZZY_SMP_NA i386 >Description: Since the recent upgrade of xorg the machine freezes without apparent reason. No core dump is produced, the screen remains steady. This can only be terminated by a hard power off. Not running powerd seems to avoid the problem. Note 1: Before completely freezing, the machine from time to time hangs for from a few tenths to several seconds. After such a freeze, "xload" shows a sharp spike from near zero to approx. 1.5..2 load which subsequently decays exponentially. Note 2: At the end of last December, I tried to upgrade this machine to 8.1 amd64. This produced totally unstable behavior/crashes, most likely also related to the video driver. At that time, I did not yet suspect cpufreq/powerd. The machine uses the following graphics controller: vgapci0@pci0:0:2:0: class=0x03 card=0x13f710cf chip=0x2a028086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 965 Express Integrated Graphics Controller' class = display subclass = VGA vgapci1@pci0:0:2:1: class=0x038000 card=0x13f710cf chip=0x2a038086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 965 Express Integrated Graphics Controller' class = display The chipset is ICH8. >How-To-Repeat: See the description above. Generally, this cannot be reproduced easily, however, the machine will crash within seconds to hours from starting X. >Fix: >Release-Note: >Audit-Trail: >Unformatted: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
kern/155321: imgact_shell integer underflow when argv[0] is longer than interp + path
>Number: 155321
>Category: kern
>Synopsis: imgact_shell integer underflow when argv[0] is longer than
>interp + path
>Confidential: no
>Severity: serious
>Priority: high
>Responsible:freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Sun Mar 06 20:00:18 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator: Devon H. O'Dell
>Release:8-STABLE
>Organization:
>Environment:
FreeBSD bigdisk.dho.apt 8.2-STABLE FreeBSD 8.2-STABLE #8: Sun Mar 6 14:20:26
EST 2011 r...@bigdisk.dho.apt:/usr/src/sys/amd64/compile/BIGDISK amd64
>Description:
In debugging a problem with Go calling execve(2), it appears that the actual
bug is in the FreeBSD kernel implementation in imgact_shell. Specifically, it
is entirely valid for argv[0] to be longer than the length of the path (treated
as "fname" in this function). We have a workaround in Go, but this should be
fixed in the kernel.
>How-To-Repeat:
Russ Cox wrote a quick to demonstrate the issue:
$ cat execve.c
#include
#include
int
main(int argc, char **argv, char **environ)
{
execve(argv[1], argv+2, environ);
perror("execve");
return 1;
}
$ cat shellscript
#!/bin/echo
$ gcc execve.c
$ cp /bin/ls .
$ ./a.out ls /bogus/ls
a.out execve.cls shellscript
$ ./a.out shellscript asdf
shellscript
$ ./a.out shellscript /bogus/shellscript
shellscript
$ ./a.out shellscript /bin/echo-shellscript
shellscript
$ ./a.out shellscript /bin/echo-shellscript1
execve: Argument list too long
>Fix:
Patch attached.
Patch attached with submission follows:
Index: sys/kern/imgact_shell.c
===
--- sys/kern/imgact_shell.c (revision 219345)
+++ sys/kern/imgact_shell.c (working copy)
@@ -195,16 +195,19 @@
length = (imgp->args->argc == 0) ? 0 :
strlen(imgp->args->begin_argv) + 1; /* bytes to delete */
- if (offset - length > imgp->args->stringspace) {
- if (sname != NULL)
- sbuf_delete(sname);
- return (E2BIG);
+ if (offset >= length) {
+ if (offset - length > imgp->args->stringspace) {
+ if (sname != NULL)
+ sbuf_delete(sname);
+ return (E2BIG);
+ }
+
+ bcopy(imgp->args->begin_argv + length, imgp->args->begin_argv +
offset,
+ imgp->args->endp - (imgp->args->begin_argv + length));
+
+ offset -= length; /* calculate actual adjustment
*/
}
- bcopy(imgp->args->begin_argv + length, imgp->args->begin_argv + offset,
- imgp->args->endp - (imgp->args->begin_argv + length));
-
- offset -= length; /* calculate actual adjustment */
imgp->args->begin_envv += offset;
imgp->args->endp += offset;
imgp->args->stringspace -= offset;
>Release-Note:
>Audit-Trail:
>Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/155321: imgact_shell integer underflow when argv[0] is longer than interp + path
Synopsis: imgact_shell integer underflow when argv[0] is longer than interp + path Responsible-Changed-From-To: freebsd-bugs->kib Responsible-Changed-By: kib Responsible-Changed-When: Sun Mar 6 21:02:05 UTC 2011 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=155321 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/155321: imgact_shell integer underflow when argv[0] is longer than interp + path
Actually, kib@ points out that this isn't quite correct; the correct
fix should indeed be a 1-liner, attached.
--dho
Index: sys/kern/imgact_shell.c
===
--- sys/kern/imgact_shell.c (revision 219345)
+++ sys/kern/imgact_shell.c (working copy)
@@ -195,7 +195,7 @@
length = (imgp->args->argc == 0) ? 0 :
strlen(imgp->args->begin_argv) + 1; /* bytes to delete */
- if (offset - length > imgp->args->stringspace) {
+ if (offset > length && offset - length > imgp->args->stringspace) {
if (sname != NULL)
sbuf_delete(sname);
return (E2BIG);
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/155321: imgact_shell integer underflow when argv[0] is longer than interp + path
Yeah, this has been a bug for quite some time. --dho 2011/3/6 Oliver Pinter : > under 7.4 exist too this problem > > XXX@XXX test> gcc execve.c > XXX@XXX test> cp /bin/ls . > XXX@XXX test> ./a.out ls /tmp/test/ls > a.out execve.c ls shellscript > XXX@XXX test> ./a.out shellscript asdf > shellscript > XXX@XXX test> ./a.out shellscript /tmp/test/ > a.out* execve.c ls* shellscript* > XXX@XXX test> ./a.out shellscript /tmp/test/ls > shellscript > XXX@XXX test> ./a.out shellscript /tmp/test/shellscript > shellscript > XXX@XXX test> ./a.out shellscript /bin/echo-shellscript > shellscript > XXX@XXX test> ./a.out shellscript /bin/echo-shellscript1 > execve: Argument list too long > XXX@XXX test> uname -a > FreeBSD XXX 7.4-STABLE FreeBSD 7.4-STABLE #71 r219301+472ccf9: Sun Mar > 6 19:16:46 CET 2011 XXX@XXX:/usr/obj/usr/src/sys/stable amd64 > > > On 3/6/11, Devon H. O'Dell wrote: >> Actually, kib@ points out that this isn't quite correct; the correct >> fix should indeed be a 1-liner, attached. >> >> --dho >> > ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/155321: imgact_shell integer underflow when argv[0] is longer than interp + path
under 7.4 exist too this problem XXX@XXX test> gcc execve.c XXX@XXX test> cp /bin/ls . XXX@XXX test> ./a.out ls /tmp/test/ls a.out execve.cls shellscript XXX@XXX test> ./a.out shellscript asdf shellscript XXX@XXX test> ./a.out shellscript /tmp/test/ a.out* execve.c ls* shellscript* XXX@XXX test> ./a.out shellscript /tmp/test/ls shellscript XXX@XXX test> ./a.out shellscript /tmp/test/shellscript shellscript XXX@XXX test> ./a.out shellscript /bin/echo-shellscript shellscript XXX@XXX test> ./a.out shellscript /bin/echo-shellscript1 execve: Argument list too long XXX@XXX test> uname -a FreeBSD XXX 7.4-STABLE FreeBSD 7.4-STABLE #71 r219301+472ccf9: Sun Mar 6 19:16:46 CET 2011 XXX@XXX:/usr/obj/usr/src/sys/stable amd64 On 3/6/11, Devon H. O'Dell wrote: > Actually, kib@ points out that this isn't quite correct; the correct > fix should indeed be a 1-liner, attached. > > --dho > ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Re: kern/155303: [firewire] Mounted firewire disks prevent reboot
Old Synopsis: Mounted firewire disks prevent reboot New Synopsis: [firewire] Mounted firewire disks prevent reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-firewire Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 7 05:00:04 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155303 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
