This is largely because I am not able to reproduce the bug in the debugger.

Working on a UNIX machine and using the test script only slightly adjusted from that posted in this thread, running the script as normal five times it was unable in any of the attempts to get past iteration 25 without hanging.

Running it through the debugger, on the other hand, I was unable to 'achieve' the hang, reaching 330 iterations of the Fisher's test loop without a failure.

Although I could not make any headway on the bug itself with the problem, I was able to trace the path of the data through the module--there is too much to post here, but if it is of interest I will send it as it might save anyone else looking at this problem some time.

I am able to 'repair' the bug by adding sleep statements in three places in pipe.pm, as follows: IN Statistics::R::Bridge::pipe::send:

    my $file = "$this->{LOG_DIR}/input.$n.r" ;
    sleep(2);
    while( -e $file || -e "$file._" ) {
[download]

AGAIN IN Statistics::R::Bridge::pipe::send

my ($x,$xx) ;
    sleep(2);
    while( (!$has_quit || $this->{STOPING} == 1) && -e $file && $this-
+>is_started( !$this->{STOPING} ) ) {
    ++$x ;
[download]

IN Statistics::R::Bridge::pipe::read_processR

my ($n) = ( $data =~ /(\d+)\s*$/gi );
    $n = 1 if $n eq '' ;
    sleep(1);
    return( $n , $data ) if wantarray ;
[download]

By doing this, I was able to get through 500 Fisher's test iterations on a UNIX server with no failed tests.
However, it is very slow because 5secs of artificial delay have been incorporated into each $R->send()!

My hypothesised reason for this is that the adjustment prevents process.log and the input.x.r files in the log_dir from getting out of sync with $n and $data.

The total time taken for 500 (successful) Fisher's tests with this alteration was: 358.38u 41.23s 1:23:39.62 7.9%