2008-09-17 06:03:40 problem with stdio pipe
Lorand Eötvös (HUNGARY)
Message: 62304
Hello,
I found a serious bug in the handling of the standard input/output pipes running the uClinux on Blackfin card.
System information:
Blackfin BF537
uClinux 2008r1-rc1
BusyBox v1.4.1 (2008-04-21 14:34:29 CEST) Built-in shell (msh)
Descrition of the bug: I have a 2 column plain text file, containing hostname and IP address records in each line (input.dat). A startup script reads this file to create individual configuration files and to start a measurement depending on the content.
Expectation: reading input.dat line-by-line using "cat | while" in the core of the loop a configuration file is generated and written to the /tmp folder. The filename and its content varies according to the hostname and ip address retreived from the line. Within the loop the config file is created using "cat >". Then it is expected to run a binary executable with arguments pointing to the config file in the /tmp.
__Problem__: within the loop the second appearance of the "cat" steals the pipeline from the "cat | while" and dumps its content into the /tmp/<something>.conf thus creating a very bad situation. Of course in any standard linux distro I could try the script, there was no problem.
The content of the startup script:
#! /bin/sh
ROOT=/mnt/traceroute_tomograph.dir
DATAFILE=$ROOT/input.dat
EXE=$ROOT/measurement.bin
WD=$ROOT/temp
LOG=$WD/measurement.log
mkdir -p $WD
cat $DATAFILE | while read hostname address ; do
echo -n "Measuring ${hostname}... " >> ${LOG}
OF="${WD}/${address}"
cat <<EOF > /tmp/${address}.conf
destinationPort 7777
dstIp ${address}
initQueries 10
initSendwait 500000
timeout 5000000
minTTL 1
maxTTL 16
sleep 100000
robins 1500
payoff 0
EOF
echo -n "($EXE /tmp/${address}.conf -trt ${OF}.trt -tomo ${OF}.tomo) " >> ${LOG}
$EXE /tmp/${address}.conf -trt ${OF}.trt -tomo ${OF}.tomo
echo "done." >> ${LOG}
done
A typical input.dat could contain:
test1.lan 192.168.1.1
test2.lan 192.168.1.2
test3.lan 192.168.1.3
test4.lan 192.168.1.4
QuoteReplyEditDelete
2008-09-17 10:01:39 Re: problem with stdio pipe
Kyle Schlansker (UNITED STATES)
Message: 62314
Not sure if this will help, but you could try eliminating the superfluous cat. e.g.
while read hostname address ; do
... your stuff ...
done < $DATAFILE
QuoteReplyEditDelete
2008-09-17 10:07:43 Re: problem with stdio pipe
Kyle Schlansker (UNITED STATES)
Message: 62315
scratch that -- I just tested it and it doesn't look like '<' is really implemented.
QuoteReplyEditDelete
2008-09-17 19:44:13 Re: problem with stdio pipe
Robin Getz (UNITED STATES)
Message: 62342
Lorand:
Did you try to see if it was a generic msh problem? (try msh on x86?)
-Robin
QuoteReplyEditDelete
2008-09-18 07:17:33 Re: problem with stdio pipe
Lorand Eötvös (HUNGARY)
Message: 62379
Thanx Robin for the hint.
I have not found any stand alone msh sources for x86 architecture yet.
For an x86 busybox with the ash shell the original script ran OK.
Now we tried to compile any other shells for the blackfin, however the results are rather disappointing:
- busybox ash doesn't compile for the blackfin
- busybox hush compiles, but when running it says something like: applet not found
- busybox lash the same applies like for hush
- normal uClinux sash doesn't compile
- normal uClinux minix-shell compiles, but running the script will produce a kernel ooops trace
- normal uClinux bash doesn't compile
- normal uClinux msh just does nothing, like feeding the stdin to the /dev/null
- normal uClinux nwsh compiles, but the output will not be correct, behaves just like busybox msh, we have for the default
Now it seems the msh has several problems, (stochastic handling of the control+c seems to be due this shell as well). Any idea how we can compile another shell? Or someone has good experiences with the above shells we could not compile so that it is worth giving another shoot?
QuoteReplyEditDelete
2008-09-18 07:41:26 Re: problem with stdio pipe
Lorand Eötvös (HUNGARY)
Message: 62380
OK, busybox msh with 1.10.2-2 version number _will properly run_ my script. So it is either a very old (1.4.1) busybox version for the uClinux that makes the problem or during porting the busybox to the uClinux something bad happened.
QuoteReplyEditDelete
2008-09-25 02:38:44 Re: problem with stdio pipe
Mike Frysinger (UNITED STATES)
Message: 62678
msh is the most complete shell that has been ported to work with no-mmu (lack of fork)
of course bash/ash/etc... will not work as those all require fork() ... it isnt a Blackfin issue, it's a no-mmu issue
there is no "x86 sources", there is only busybox which gets compiled for different platforms using different toolchains