Bug 22900 - Perl Scripts executing with debug mode "-w" using DBI causing child hangs
Summary: Perl Scripts executing with debug mode "-w" using DBI causing child hangs
Status: CLOSED DUPLICATE of bug 22030
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Core (show other bugs)
Version: 2.0.47
Hardware: Sun Solaris
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-09-02 22:14 UTC by Nojan Moshiri
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nojan Moshiri 2003-09-02 22:14:02 UTC
We are running apache 2.0.47 compiled with prefork model. We are running with
some modules static and some shared (Attached as APPENDIX A & B below). We are
running a pretty standard CGI environment (No mod_perl or php) using perl 5.6.1
on Solaris 2.8.

We have seen two examples where perl scripts have caused apache children and
their forked off CGIs to hang indefinitely when there is a lot of debug output
with perl -w in situations where DBI is used.

For example, we have a script that was run with perl -w and includes DBI using a
use statement (use DBI;) When the DBI call was made to fetch data, there were a
lot of errors in regards to a particular variable being unitialized, pretty
standard Perl error.  However, with -w on, Apache hangs.  With -w OFF, apache
would not hang.  There were some 600 rows fetched and Apache would hang
somewhere around 160 rows.

The same script, executed from the command line would execute fine each and
every time. Also, the same script would execute fine from Apache 1.3.26.   I can
try to provide a script to reproduce this but it would have to include DBI Calls.  

I have created a script with no DBI calls which generates a ton of errors with
perl -w  and this only does not trigger the problem.  The key element seems to
be the DBI call.
 

Any ideas?

APPENDIX A - Modules compiled Static
=====================================
  core.c
  mod_access.c
  mod_auth.c
  mod_log_config.c
  mod_env.c
  mod_usertrack.c
  prefork.c
  http_core.c
  mod_mime.c
  mod_status.c
  mod_dir.c
  mod_imap.c
  mod_so.c

APPENDIX B - Modules loaded at run-time
=========================================
LoadModule ldap_module modules/mod_ldap.so
LoadModule auth_ldap_module modules/mod_auth_ldap.so
LoadModule include_module modules/mod_include.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
#LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
#LoadModule proxy_http_module modules/mod_proxy_http.so
<IfDefine SSL>
LoadModule ssl_module modules/mod_ssl.so
</IfDefine>
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule actions_module modules/mod_actions.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
Comment 1 Jeff Trawick 2003-09-03 13:46:36 UTC
The hang comes when the CGI writes too much to stderr.

You might try http://www.apache.org/~trawick/mod_cgi.c, which is a hacked up
version of mod_cgi that handles stdin/stdout/stderr better on Unix platforms.

*** This bug has been marked as a duplicate of 22030 ***
Comment 2 Nojan Moshiri 2003-09-03 16:59:56 UTC
thanks, this (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22030) is indeed
the problem.