2008-09-17 06:03:40     problem with stdio pipe

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