Apache, mod_perl, C++, XS and Shared Memory

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

Hi,

I'm pretty new to the C++ and XS embedding and I'm not sure if this the correct section to place my question.

I've created a XS module that includes precompiled libraries and functions. One of these included C++ functions creates a shared memory segment in order to communicate with another process. Using apache's mod_cgi and simple perl scripts it works. But using mod_perl does not work.

How can I find out where the problem is? Does mod_perl deny access to the shared memory? Does anybody have a clue or an advice where I can start investigating? One possible issue could be, that the main apache process is started as root and all child processes are run as www-data. But the shared memory segment (shown by ipcs) is owned by www-data so it should be ok.

I have no possibility to debug the libs or anything like that.

Kind regards, Olli

Ubuntu 10.04.1 LTS
perl v5.10.1
libapache2-mod-perl2  2.0.4-6ubuntu1

Server version: Apache/2.2.14 (Ubuntu)
Server built:   Apr 13 2010 19:29:28
Server's Module Magic Number: 20051115:23
Server loaded:  APR 1.3.8, APR-Util 1.3.9
Compiled using: APR 1.3.8, APR-Util 1.3.9
Architecture:   32-bit
Server MPM:     Worker
  threaded:     yes (fixed thread count)
    forked:     yes (variable process count)
Server compiled with....
 -D APACHE_MPM_DIR="server/mpm/worker"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT=""
 -D SUEXEC_BIN="/usr/lib/apache2/suexec"
 -D DEFAULT_PIDLOG="/var/run/apache2.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types"
 -D SERVER_CONFIG_FILE="/etc/apache2/apache2.conf"
[download]

Comment on Apache, mod_perl, C++, XS and Shared Memory Download Code

Replies are listed 'Best First'.
Re: Apache, mod_perl, C++, XS and Shared Memory by cdarke (Prior) on Sep 06, 2010 at 12:26 UTC
using mod_perl does not work. Can you be more specific? Are you checking the return code from all API calls? Do you get an error reported anywhere? One possibility is that `ftok()` is not giving a consistent result, you might like to trace that. In particular check that it is not returning -1, you might not have permissions to access the file inode.	[reply] [d/l]
Re^2: Apache, mod_perl, C++, XS and Shared Memory by oseeliger (Initiate) on Sep 06, 2010 at 12:52 UTC
Can you be more specific? The module's XS file has a prototype function declation `int get_registration_status();` [download] which is implemented in my c++ file `int get_registration_status () { return RegisterGetStatus(); }` [download] The "RegisterGetStatus" is the function that is part of the static linked lib. The only error I get reported is that the return code is not the one I expected. No messages in apache's error log nor from mod_perl or anything. As I've already stated I can't debug this lib (maybe because I don't know how to do it ;-). Am I able to trace or debug into the lib when it's compiled without debug information? Is there any difference in how mod_cgi and mod_perl handle the access to shared memory segments?	[reply] [d/l] [select]
Re^3: Apache, mod_perl, C++, XS and Shared Memory by cdarke (Prior) on Sep 08, 2010 at 07:23 UTC
If the module is not giving you any useful error information then you have several courses of action. You should consult the documentation for the module. If that is unhelpful then contact the supplier. Otherwise you are reduced to tracing the kernel calls. Tracing the kernel calls should give you the exact errors and object names if the problem is related to permissions, as you suspect. You will need a tool such as truss (on Sun) or strace (on Linux, and others). Display the process PID ($$), or write it to a file, then pause your process just before the shared object is created. Then attach truss or strace to the process using the -p option. You will need to be signed on as the same userid, or root. Now allow the application to continue. Once you get sufficient information then kill the truss/strace using <CTRL>C. If there is too much data output (and there often is) then use the -o option to save it to a file for later analysis.	[reply]
Re: Apache, mod_perl, C++, XS and Shared Memory by Khen1950fx (Canon) on Sep 06, 2010 at 21:35 UTC
You need to post some code. Without it, everything's just a guess. mod_perl doesn't deny access to shared memory. You can use GTop to get a process shared memory size and total size. For example, `#!/usr/bin/perl use strict; use warnings; use GTop (); my $gtop = GTop->new; my $proc_mem = $gtop->proc_mem(2872); print "Shared memory of the current processes: ", my $share = $gtop->proc_mem($$)->share, "\n"; print "Total memory size of current processes: ", my $size = $gtop->proc_mem($$)->size, "\n";` [download] For more help, see: mod_perl intro Measuring_the_Memory_of_the_Process Update: This will get the shared memory and size for a single process: `#!perl use strict; use warnings; use GTop (); use Data::Dumper::Concise; my $gtop = GTop->new(@ARGV); my $pid = 2518; my $proc_mem = $gtop->proc_mem($pid); for ($pid) { warn Dumper my $share = $proc_mem->share, my $size = $proc_mem->size; }` [download]	[reply] [d/l] [select]
Re^2: Apache, mod_perl, C++, XS and Shared Memory by Anonymous Monk on Sep 13, 2010 at 10:56 UTC
Thank you all for you effort, I finally solved it. The problem was that the linked library expected some environment variable to be set; and I forgot to set them :-( Now after having these variables set everything works fine and it had nothing to do with the shared memory segments. --- closed ---	[reply]