Bug #1544
closed
bad awk output on vkernel
0%
Description
I'd like to add this as a bug so as it's not forgotten, or attract
someone else's attention. It also seems to affect pkgsrc packages
using awk in its configure script, for instance.
On Tue, Aug 18, 2009 at 09:17:51PM +0900, YONETANI Tomokazu wrote:
On Thu, Aug 13, 2009 at 11:48:18PM -0700, Matthew Dillon wrote:
Is this with the latest master ? I did fix some pipe bugs last week
which could very well cause this sort of behavior (where the data gets
corrupted through the pipe). I'm pretty sure I got all the bugs, there
shouldn't be any left.If it isn't that I'll have to try to reproduce it on a test bed and
then track the issue down.I'd say it's not a pipe issue, but specific to running awk on vkernel,
because this perl version never produces bad output on vkernel:my $SUBSEP = "\034";
my $flag = 0;
my @record;
while (<>) {
chomp;
if (/^[ \t]*(;|$)/) {
$flag = 0;
next;
}
if (/^[^ \t]/) {
if ($flag == 0) {
push(@record, $_);
$flag = 1;
}
else {
my $l = @record - 1;
$record[$l] .= $SUBSEP;
$record[$l] .= $_;
}
}
}foreach (sort @record) {
print $_, "\n";
}My guess is that awk on vkernel has problem handling an array of long
strings, especially its elements are assigned to in a non-sequential way;
if I commented the line calling sort() function and it greatly reduced
the probability of inconsistent output :)I also tried gawk from pkgsrc, but it seems to have similar issue.
Probably I need to take a closer look at the source code.
Updated by dillon about 15 years ago
:I'd like to add this as a bug so as it's not forgotten, or attract
:someone else's attention. It also seems to affect pkgsrc packages
:using awk in its configure script, for instance.
:
:> I'd say it's not a pipe issue, but specific to running awk on vkernel,
:> because this perl version never produces bad output on vkernel:
:>
I've reproduced the problem in the vkernel.I reproduced your sorting test, where commenting out the
core of the sort code makes the problem occur less often.
When it did mess up I got:f056eddb732fb0e453dcab96508dc73a
f056eddb732fb0e453dcab96508dc73a
f056eddb732fb0e453dcab96508dc73a
f056eddb732fb0e453dcab96508dc73a
/usr/bin/awk: trying to access out of range field -2147483648
input record number 819, file common.opt
source line number 41I replaced the /bin/sh last=`...` backtick assignment with a
redirect to a file and that file showed corruption, so we can
rule out /bin/sh's variable assignment.I think what we are seeing is either VM memory corruption in the
vkernel implementation, which seems unlikely because the VM system
is not being stressed, or execution state corruption. I kinda
suspect the cpu flags... maybe the direction flag is getting
corrupted. I am looking into it.-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by dillon about 15 years ago
Problem solved!
The recent work on the vkernel which enabled preemptive thread
switching introduced a race condition in go_user() between the
determination of the FP state and the call to vmspace_ctl().The FP state could wind up getting changed by a preemptive thread
switch and result in corruption of the FP state in the virtual
user process when vmspace_ctl() was finally called.-Matt
Matthew Dillon
<dillon@backplane.com>
Updated by