tachyon has asked for the wisdom of the Perl Monks concerning the following question:

This is a very odd problem that has taken me the last 4 hours to isolate, debug and sort of cure. Here is the cure:

sleep 1; # <--- WORKS! #use Time::HiRes 'usleep'; # <--- DOES NOT!!!!! #usleep( 2000 ); # <--- ???? my $html = ui_template( 'Regex Editor', '', $html ); # $html =~ s/\W/_/g; # no effect print $html; # close STDIN; close STDOUT; # no effect exit 0; # no effect
Now to the details of the problem......

The addition of the sleep 1 allows the script to function. Without it it chokes in an error log free way. First some background:

In the course of debugging this behaviour the following observations were made:

I have no idea why this is happening, and like most programmers worry about errors for which I can't find a reason, even if I can kludge it over.

Suggestions appreciated.

cheers

tachyon

The script logic preceeding the noted code follows. None of the subs fork, so they should do their stuff, finish and return

#!/usr/bin/perl -w my $REGEX_CGI = 'http://devel3.ourdomain.org/cgi-bin/regex.pl'; use strict; $|++; use lib "/devel/www/cgi-bin"; use OurModules::CGI; use OurModules::Config; use OurModules::DBIFunctions qw( do_dbi_connect regex_get_data regex_delete regex_update regex_new validate_regex ); use OurModules::UI qw ( ui_template ui_user_error ui_permission_denied + pretty_table ); use OurModules::Session qw ( login_session ); use OurModules::Perms qw( allow_s_re_editor ); my $q = OurModules::CGI->new(); print $q->header; my $dbh = do_dbi_connect( $DB_TYPE, $DB_NAME, $FILTER_USERNAME, $FILTE +R_PASSWORD ); END{ $dbh->disconnect if $dbh }; # session code removed, substitued with null values my $session = ''; my $user_id = 1; if ( $q->param('action') and $q->param('action') eq 'update' ) { my $html = ''; my $need_hup = 0; for my $param ( sort $q->param() ) { if ( $param =~ m/update_(\d+)$/ ) { next if $q->param($param) eq 'OK'; my $regex_id = $1; $need_hup = 1; if ( $q->param($param) eq 'DELETE' ) { $html .= regex_delete( $dbh, $regex_id ); } else { $html .= regex_update( $dbh, $regex_id, $q->param("reg +ex_string_$regex_id"), $q->param("location_$regex_id"), $q->param("co +mments_$regex_id"), $user_id ); } } elsif ( $param =~ m/new/ ) { next unless $q->param($param) eq 'NEW'; $need_hup = 1; $html .= regex_new( $dbh, $q->param("regex_string_new"), $ +q->param("location_new"), $q->param("comments_new"), $user_id ); } } #do{ system( 'sudo', $SEND_HUP ) and ui_system_error( "Could not H +UP redirector! $SEND_HUP $?" ) } if $need_hup; $html ||= 'No Updates Found'; $html =<<HTML; <form method="POST" action="$REGEX_CGI"> <input type="hidden" name="session" value="$session"> <pre> Doing Updates: $html Done! </pre> <input type="submit" name="back" value="Back to Regex Editor"> </form> HTML sleep 1; # <--- WORKS! #use Time::HiRes 'usleep'; # <--- DOES NOT!!!!! #usleep( 2000 ); my $html = ui_template( 'Regex Editor', '', $html ); # $html =~ s/\W/_/g; # no effect print $html; # close STDIN; close STDOUT; # no effect exit 0; # no effect } else { show_form( $dbh, $q, $session ); } exit 0; #--------------------------------------------------------------------- +---------- # subroutines #--------------------------------------------------------------------- +----------

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Replies are listed 'Best First'.
Re: Odd bug - Sleep 1 cures CGI proxy issue - But Why???
by Roger (Parson) on Sep 05, 2003 at 22:48 UTC
    This smells like a unix issue with usleep.

    The perl Time::HiRes module is implemented over the unix usleep function, which uses the real-time timer of the process. Each unix process has only one real-time timer. Now, what happens is that if Apache server has already setup the real-time timer for the cgi process, subsequent calls in the perl script to usleep will have no effect.

    Have you timed the usleep function to see if it has really suspended the process by 2 seconds?

      If that's the problem, select(undef,undef,undef,2) is a good alternative.

      Another possibility is that the delivery of the ALRM signal is what's fixing the problem. Maybe kill $$,'CONT' will achieve the same thing without the pause.

      Not that either of these is a good long-term solution, but knowing that one fixes the problem and one doesn't might help point you to why it's getting stuck.

      usleep is microseconds, not milliseconds, so it's really 0.002 sec
Re: Odd bug - Sleep 1 cures CGI proxy issue - But Why???
by menolly (Hermit) on Sep 05, 2003 at 19:07 UTC
    Have you tested with multiple browsers/versions? We've seen some odd, browser-dependent behavior with large forms occasionally. This is probably not your issue, but it's worth ruling out.
Re: Odd bug - Sleep 1 cures CGI proxy issue - But Why???
by sgifford (Prior) on Sep 05, 2003 at 19:09 UTC
    It could be a browser bug. Have you reproduced it in different browsers? What do you see if you use wget/GET/telnet to test it?