Bug 51371

Summary: wrong guards around 'apr_procattr_limit_set' in mod_cgi.c
Product: Apache httpd-2 Reporter: Anthony Foiani <anthony.foiani>
Component: mod_cgiAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: normal Keywords: FixedInTrunk
Priority: P2    
Version: 2.2.19   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Attachments: config.log output that fails to find 'struct rlimit'

Description Anthony Foiani 2011-06-14 06:38:11 UTC
I have other configuration issues I need to sort out, but this is a problem with the core code in a clean 2.2.19 build.

The symptom is an undefined reference to apr_procattr_limit_set when trying to link mod_cgi.so.

In srclib/apr/threadproc/unix/proc.c, the definition of apr_procattr_limit_set is guarded by APR_HAVE_STRUCT_RLIMIT (at about line 670):

  #if APR_HAVE_STRUCT_RLIMIT
  APR_DECLARE(apr_status_t) apr_procattr_limit_set(apr_procattr_t *attr,
                                                   apr_int32_t what,
                                                   struct rlimit *limit)
  {
  /* ... */
  }
  #endif /* APR_HAVE_STRUCT_RLIMIT */

But it's used in modules/generators/mod_cgi.c with only RLIMIT_CPU, RLIMIT_DATA, or RLIMIT_NPROC guards (at about line 429):

  #ifdef RLIMIT_CPU
          ((rc = apr_procattr_limit_set(procattr, APR_LIMIT_CPU,
                                        conf->limit_cpu)) != APR_SUCCESS) ||
  #endif
  #if defined(RLIMIT_DATA) || defined(RLIMIT_VMEM) || defined(RLIMIT_AS)
          ((rc = apr_procattr_limit_set(procattr, APR_LIMIT_MEM,
                                        conf->limit_mem)) != APR_SUCCESS) ||
  #endif
  #ifdef RLIMIT_NPROC
          ((rc = apr_procattr_limit_set(procattr, APR_LIMIT_NPROC,
                                        conf->limit_nproc)) != APR_SUCCESS) ||
  #endif

The obvious fix is to just add APR_HAVE_STRUCT_RLIMIT guards around that bit, but there might be something non-obvious going on.

This might also be related to bug 40287, but I don't have the resources to pull out the 2.0 codebase and verify.
Comment 1 Eric Covener 2011-06-17 12:57:02 UTC
Can you post config.log from APR where RLIMIT_* was defined but APR autoconf decided to not set APR_HAVE_STRUCT_RLIMIT?   And where "struct rlimit" is defined in your system?

(I assume that's what cgi is relying on)
Comment 2 Anthony Foiani 2011-06-17 21:37:52 UTC
(In reply to comment #1)
> Can you post config.log from APR where RLIMIT_* was defined but APR autoconf
> decided to not set APR_HAVE_STRUCT_RLIMIT?   And where "struct rlimit" is
> defined in your system?

It's a bit messy, as I'm cross-compiling: building on linux (Fedora 14 x86_64) for a powerpc linux target.

As such, I'm running the httpd (and hence apr) config machinery against the cross-compiler and the kernel headers for the target system, not my local system.

I'll see if I can't reproduce the problem, but I have been in "fix and move on mode" since I reported this issue, so getting back to that exact configuration might be difficult.  My actual configuration stanza is as follows; the extra variables are there to keep the configuration script from trying to run target binaries on the host.

    ac_default_prefix=/                                 \
    ac_cv_sizeof_struct_iovec=8                         \
    ac_cv_struct_rlimit=yes                             \
    ac_cv_define_PTHREAD_PROCESS_SHARED=yes             \
    ac_cv_func_setpgrp_void=yes                         \
    ac_cv_file__dev_zero=yes                            \
    ac_site_file=NONE                                   \
    ap_cv_void_ptr_lt_long=no                           \
    apr_cv_tcp_nodelay_with_cork=yes                    \
    apr_cv_mutex_robust_shared=yes                      \
    apr_cv_process_shared_works=yes                     \
    manualdir=/doc/httpd-manual                         \
    ./configure                                         \
        --prefix=/                                      \
        --sysconfdir=/etc                               \
        --datadir=/www                                  \
        --docdir=/doc                                   \
        --host="$TARGET_TUPLE"                          \
        --enable-auth-digest                            \
        --enable-deflate --with-z="$PLATFORM_STAGE"     \
        --enable-expires                                \
        --enable-headers                                \
        --enable-logio                                  \
        --enable-ssl=no                                 \
      || exit 1

> (I assume that's what cgi is relying on)

I'm not sure how to describe the "relies on" relationship any better than in my original problem description: threadproc uses one guard to determine whether it should provide a particular function, while mod_cgi uses a different guard to determine whether it should call said function.

It's clear that mod_cgi doesn't *need* this call; it will still work even without it, but it just won't enforce resource limits on child processes.
Comment 3 Anthony Foiani 2011-06-18 04:37:40 UTC
Created attachment 27170 [details]
config.log output that fails to find 'struct rlimit'

config.log for a session which experienced the problem described in the initial description of this bug.
Comment 4 Anirudh takkallapally 2011-06-23 22:08:18 UTC
Did you find a solution for this?, i am having the same issue.
Comment 5 Anthony Foiani 2011-06-23 22:36:09 UTC
(In reply to comment #4)
> Did you find a solution for this?, i am having the same issue.

It's not clear that the developers think it's a real problem, but you can work around it by specifying the appropriate autoconf variable when you run './configure' (as in comment 2). E.g.,

  ac_cv_struct_rlimit=yes ./configure --with...

Hope this helps!
Comment 6 Eric Covener 2011-09-17 17:01:40 UTC
fixed in trunk r1172019.
Comment 7 Stefan Fritsch 2012-02-26 17:12:21 UTC
fixed in 2.4.1