Sorry,

A small correction. The test works with a "home compiled" perl 5.16.3 without ithreads support. With 5.22.1 without ithreads support I run into the same issue that r1702395 should have solved with sprintf warnings.

While I'm no expert in this, I believe that the comment in r1702395 is wrong. It's not because of the thread context that the number of arguments is wrong, it's because of the way WrapXS.pm handles functions with variable parameter length (i.e. ... functions).

In the .xs code items is the number of elements in the MARK array. However when WrapXS.pm generates code for a ... function, it will increment MARK, so that it points to the second argument to the function. It will not, however decrement items, which means that items and MARK now are out of sync. I suspect that MARK is incremented to skip the object that the function is called on.

I've attached a simple patch that updates the comment and removes the ifdef around the decrementation of items, which solves the test-failures for non-threaded perl 5.22.

Klaus S. Madsen, Udvikler, k...@jobindex.dk
Jobindex A/S, Holger Danskes Vej 91, 2000 Frederiksberg
Tlf +45 38 32 33 55, Dir +45 38 32 33 70
http://www.jobindex.dk/

On 2016-03-02 11:15, Klaus S. Madsen wrote:
Hi,

I'm looking into upgrading our perl version to 5.22.1. Since mod_perl 2.0.9 doen't work with 5.22, I thought that it would be a good idea to test the SVN version of mod_perl.

We compile our own perl, and we compile it without ithread support, which the new env-support doesn't appear to work with. I get the following compile errors:

modperl_env.c: In function 'modperl_env_init':
modperl_env.c:657:10: error: 'my_perl' undeclared (first use in this function) modperl_env.c:657:10: note: each undeclared identifier is reported only once for each function it appears in
modperl_env.c: In function 'modperl_env_unload':
modperl_env.c:688:10: error: 'my_perl' undeclared (first use in this function)

As far as I can tell, this is because pTHX expands to define a my_perl parameter for modperl_env_init and modperl_env_unload if perl is compiled with ithreads support. However without ithreads support pTHX expands to nothing, causing the compile error.

To fix this, I've tried to simply delete the if (!my_perl) tests in modperl_env_init and modperl_env_unload. I'm fairly sure that this is safe to do for modperl_env_unload, since it is only called from modperl_perl_destruct, which appears to have a perl interpreter instance. However I'm not so sure for modperl_env_init.

Removing those two if-statements reveal that we should call modperl_env_unload with aTHX as the parameter in modperl_perl_descruct, so that the number of arguments is correct both with and without ithread support enabled.

The attached patch makes both changes. Apply with -p0.

I've tested this against our "home-compiled" perl 5.22 where it now compiles and passes the tests. I've also tried against the Ubuntu 12.04 supplied perl with ithreads support, which also compiles and passes all the tests.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Index: xs/Apache2/RequestIO/Apache2__RequestIO.h
===================================================================
--- xs/Apache2/RequestIO/Apache2__RequestIO.h	(revision 1733039)
+++ xs/Apache2/RequestIO/Apache2__RequestIO.h	(working copy)
@@ -111,13 +111,11 @@
 
     rcfg = modperl_config_req_get(r);
 
-    /* Reduce items by 1 for threaded builds since it otherwise includes
-     * the thread context, which shouldn't be included in the count of
-     * arguments being given to the sprintf() call.
+    /* Reduce items by 1 since it otherwise includes the
+     * Apache2::RequestRec object, which shouldn't be included in the
+     * count of arguments being given to the sprintf() call.
      */
-#ifdef USE_ITHREADS
     --items;
-#endif
 
     /* XXX: we could have an rcfg->sprintf_buffer to reuse this SV
      * across requests

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org

Reply via email to