Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Thanks a lot Perrin for advising to run prefork. I switched to prefork and I am now able to successfully run apache2 under the debugger/valgrind. I was finally able to narrow down the problem to symbol clashes between two shared libraries for which perl bindings were written. Using the right linker and objcopy options I am able to take care of the problem. On 8/14/07, Perrin Harkins [EMAIL PROTECTED] wrote: On 8/14/07, Manoj Bist [EMAIL PROTECTED] wrote: Is it possible to change the stack size in mod_perl(Similar to ulimit -s unlimited etc.)? The stack size? What are you trying to do? I'm not aware of anything special about stack size in mod_perl that would be different from any other compiled C program. Also, why do you mention threads? Are you running a threaded MPM? Unless you're on Windows, I'd advise you to run prefork. - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Is it possible to change the stack size in mod_perl(Similar to ulimit -s unlimited etc.)? Thanks, Manoj. On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: Hi Perrin, Is there some recommended way to detect if STDOUT is being manipulated? This is what I am doing. 1. Build a standalone binary that uses this lib. 2. Run this binary in the debugger and insert breakpoints in read, write, open and close. The library is using TCP sockets to communicate with the server. Is there some way to debug apache/mod_perl in the debugger? Thanks a lot, Manoj. On 8/13/07, Perrin Harkins [EMAIL PROTECTED] wrote: On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: Thanks for the response. The C library is a third party library which does the following: - Connect to a server running on port 7000 on the local machine. - Make an initialize call ==This call is consistently failing under mod_perl. Okay, so that's what you need to focus on. Do you know if it's connecting over TCP sockets or pipes? There may be issues if it's trying to manipulate STDOUT. The startup.pl that we are using has only 5 lines. I don't see how this could cause you trouble, unless you are loading other things directly from httpd.conf. It probably has to do with STDOUT. - Perrin
Re: Scripts works under CGI but not under mod_perl
On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: Is there some recommended way to detect if STDOUT is being manipulated? The source code is usually the easiest way. The library is using TCP sockets to communicate with the server. That usually is not a problem under mod_perl. Is there some way to debug apache/mod_perl in the debugger? Sure. You'll find information on debugging at both the perl and C level here: http://modperlbook.org/html/ch21_01.html - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
On 8/14/07, Manoj Bist [EMAIL PROTECTED] wrote: Is it possible to change the stack size in mod_perl(Similar to ulimit -s unlimited etc.)? The stack size? What are you trying to do? I'm not aware of anything special about stack size in mod_perl that would be different from any other compiled C program. Also, why do you mention threads? Are you running a threaded MPM? Unless you're on Windows, I'd advise you to run prefork. - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Perrin Harkins wrote: On 8/14/07, Manoj Bist [EMAIL PROTECTED] wrote: Is it possible to change the stack size in mod_perl(Similar to ulimit -s unlimited etc.)? The stack size? What are you trying to do? I'm not aware of anything special about stack size in mod_perl that would be different from any other compiled C program. http://httpd.apache.org/docs/2.2/mod/quickreference.html ^F stack Also, why do you mention threads? Are you running a threaded MPM? Unless you're on Windows, I'd advise you to run prefork. Few issues here running threaded, but that depends on a host of other decisions (ancient library bindings, different host contexts, etc).
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
On 8/14/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Few issues here running threaded, but that depends on a host of other decisions (ancient library bindings, different host contexts, etc). It definitely could be the cause of issues with a C library using sockets that isn't written to be threadsafe. The general reason to use prefork though is the more efficient use of memory due to copy-on-write. - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Perrin Harkins wrote: It definitely could be the cause of issues with a C library using sockets that isn't written to be threadsafe. The general reason to use prefork though is the more efficient use of memory due to copy-on-write. I'm familiar with copy-on-write. Could you elaborate? From httpd's perspective, those same gains are true of worker as well. One of my more favorite features of the pre-SMS apr pools was my patch to permit locking a pool read-only. This let us see that folks were not jinxing the copy on write behavior of the process and config pools in httpd by writing back data (and breaking the read-only paged copy). Of course two iterations later, my hacks were ripped from APR. Another round-tuit to restore that behavior :) Bill
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
On 8/14/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: I'm familiar with copy-on-write. Could you elaborate? From httpd's perspective, those same gains are true of worker as well. Perl's threads don't share much. Most of the memory is used for data structures, and these are fully duplicated in every thread. With forking, copy-on-write effectively shares much of this data, resulting in a major reduction in memory used. One of my more favorite features of the pre-SMS apr pools was my patch to permit locking a pool read-only. This let us see that folks were not jinxing the copy on write behavior of the process and config pools in httpd by writing back data (and breaking the read-only paged copy). Perl doesn't use those pools anyway (well, mod_perl can use them, but normal perl data storage doesn't go into them). - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Hi Perrin, Thanks for the response. I am using threaded MPM. The self-contained program that I created crashes if I set the stack size to 256K (using ulimit -s). At higher stack size limits it works fine. That's why I want to try bumping up the stack size for apache/mod_perl. So far I have not been able to find out if that is possible in apache2. 0. On 8/14/07, Perrin Harkins [EMAIL PROTECTED] wrote: On 8/14/07, Manoj Bist [EMAIL PROTECTED] wrote: Is it possible to change the stack size in mod_perl(Similar to ulimit -s unlimited etc.)? The stack size? What are you trying to do? I'm not aware of anything special about stack size in mod_perl that would be different from any other compiled C program. Also, why do you mention threads? Are you running a threaded MPM? Unless you're on Windows, I'd advise you to run prefork. - Perrin
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
Manoj Bist wrote: That's why I want to try bumping up the stack size for apache/mod_perl. So far I have not been able to find out if that is possible in apache2. 0. Dude - I gave you the answer hours ago http://httpd.apache.org/docs/2.0/mod/quickreference.html search for the word stack and answer your own question
Re: Scripts works under CGI but not under mod_perl (and thread stack size)
William A. Rowe, Jr. wrote: http://httpd.apache.org/docs/2.0/mod/quickreference.html search for the word stack and answer your own question So... testing against worker mpm, the answer is no; ThreadStackSize is not a supported directive. Sorry - I'm not often in the internals of prefork/worker, so I'm going on other MPM's. But I thought this one was already common :( Bill
Scripts works under CGI but not under mod_perl
Hi, I created a perl binding for a third party C library using swig. This works fine under CGI but consistently fails under mod_perl. Is there a known set of calls(mulithreading etc.) that is not expected to work under mod_perl? I have gone through almost all the mod_perl caveats that I could google. I have been struggling with this for quite some time. I would really appreciate any insights/pointers/ideas on troubleshooting this. Thanks, Manoj.
Re: Scripts works under CGI but not under mod_perl
On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: I created a perl binding for a third party C library using swig. This works fine under CGI but consistently fails under mod_perl. Is there a known set of calls(mulithreading etc.) that is not expected to work under mod_perl? Modules with C code normally work fine with mod_perl. The only generic problems I can think of are ones where you open sockets or files in startup.pl and then fork and try to share them. Can you tell us more about what the C library does and how it fails? - Perrin
Re: Scripts works under CGI but not under mod_perl
Hi Perrin, Thanks for the response. The C library is a third party library which does the following: - Connect to a server running on port 7000 on the local machine. - Make an initialize call ==This call is consistently failing under mod_perl. - Grab binary data returned by the server. What is most baffling is that the same perl code works fine when run as a standalone application or as CGI but consistently fails under mod_perl. The parameters passed to these call are the following: - a struct which contains a couple of character strings - pointer to a handle that would be filled up after the call. I have tried running a standalone perl application that uses the perl binding under valgrind. However it did not expose memory issues. The startup.pl that we are using has only 5 lines. I have included it here. 11 use ModPerl::Registry; 12 use Apache2::Const; 13 use CGI qw(-compile :all); 14 use CGI::Carp (); 15 1; - Manoj. On 8/13/07, Perrin Harkins [EMAIL PROTECTED] wrote: On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: I created a perl binding for a third party C library using swig. This works fine under CGI but consistently fails under mod_perl. Is there a known set of calls(mulithreading etc.) that is not expected to work under mod_perl? Modules with C code normally work fine with mod_perl. The only generic problems I can think of are ones where you open sockets or files in startup.pl and then fork and try to share them. Can you tell us more about what the C library does and how it fails? - Perrin
Re: Scripts works under CGI but not under mod_perl
On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: Thanks for the response. The C library is a third party library which does the following: - Connect to a server running on port 7000 on the local machine. - Make an initialize call ==This call is consistently failing under mod_perl. Okay, so that's what you need to focus on. Do you know if it's connecting over TCP sockets or pipes? There may be issues if it's trying to manipulate STDOUT. The startup.pl that we are using has only 5 lines. I don't see how this could cause you trouble, unless you are loading other things directly from httpd.conf. It probably has to do with STDOUT. - Perrin
Re: Scripts works under CGI but not under mod_perl
Hi Perrin, Is there some recommended way to detect if STDOUT is being manipulated? This is what I am doing. 1. Build a standalone binary that uses this lib. 2. Run this binary in the debugger and insert breakpoints in read, write, open and close. The library is using TCP sockets to communicate with the server. Is there some way to debug apache/mod_perl in the debugger? Thanks a lot, Manoj. On 8/13/07, Perrin Harkins [EMAIL PROTECTED] wrote: On 8/13/07, Manoj Bist [EMAIL PROTECTED] wrote: Thanks for the response. The C library is a third party library which does the following: - Connect to a server running on port 7000 on the local machine. - Make an initialize call ==This call is consistently failing under mod_perl. Okay, so that's what you need to focus on. Do you know if it's connecting over TCP sockets or pipes? There may be issues if it's trying to manipulate STDOUT. The startup.pl that we are using has only 5 lines. I don't see how this could cause you trouble, unless you are loading other things directly from httpd.conf. It probably has to do with STDOUT. - Perrin
