# extension and apache 2.x compatibility issue. - Thread: https://externals.io/message/21983 - Original archive: https://news-web.php.net/php.internals/21983 - Started by D. Walsh on 2006-02-22T05:48:11+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #21983 — D. Walsh — 2006-02-22T05:48:11+00:00 URL: https://externals.io/message/21983#21983 I had an issue with an extension that I previously posted to this list and it was suggested I update to the newer API which might provide a solution to the problem. Taking a somewhat safe approach I tackled converting the rrdtool extension first since it was similar in functionality and protocol to my ramdisk extension. Trying to convert to the new API wasn't as easy as it had been suggested/reported. Steph Fox and I worked on it for several days before we finally got it worked out. I tested the extension for the last week under Apache 1.3.33 and found that the extension seemed to take less time to perform it's functions which was well worth the effort to convert to the newer API so thank you for the kick in this area. I then compiled for Apache 2 and found that I was still experiencing the same issues so I'm sad to report that this did not correct the problem. I realize that hearing "it doesn't work" or "it failed" isn't descriptive so I'll try to provide a little more information on the problem. Bear in mind that I have stepped back in time a little and have gone with linking the RRDTool library in an attempt to remove as many unknown variables from the equation as I possibly could and allow testing with various version of the RRDTool library but the RRDTool extension Tobias and I will be submitting for bundling with PHP will not require linking to an external RRDTool library as it will be entirely self contained however, the ability to link to an external RRDTool library will be available provided we can get all of our ducks in a row and satisfy the PHP license requirements (which may already be the case). Building PHP for Apache 1.3, a php script calls the rrd_graph function with a string (filename), an array (data to process) and a long (the array count) and returns an array containing the generated output file details. PHP seems to pass the variables to the linked library function without any issues, generates the output file and returns an array of the details with success. Building PHP for Apache 2.0 and Apache 2.2, passing the same information should yield the same results but it doesn't. The output file is never generated, the library complains that the array being passed is incomplete and invalid and no array is returned. I've tried using both 1.0.x and 1.2.x versions of the RRDTool library which resulted in the same issue so I've ruled out the library function as the cause of the problem since they all worked as expected when building PHP for Apache 1.3. Here's the entire rrd_graph function currently being used in the testing phase, I've gone over the available API with Steph who provided a lot of time, insight and assistance in helping me convert to the new API so at this time I'm not sure what the issue is or how to resolve it so if someone has ideas or sees a problem I'd be most grateful to hear about it. ________________________________________________________________________ _____________________________ PHP_FUNCTION(rrd_graph) { char *file; zval *args, *entry, *p_calcpr; HashTable *args_arr; char **argv, **calcpr; long php_argc, argc; uint file_len; int xsize, ysize, i = 0; double ymin = 0.0, ymax = 0.0; if ( rrd_test_error() ) rrd_clear_error(); if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sal", &file, &file_len, &args, &php_argc) == FAILURE) { return; } if ( args->type != IS_ARRAY ) { php_error(E_WARNING, "2nd Variable passed to rrd_graph is not an array!\n"); RETURN_FALSE; } args_arr = args->value.ht; argc = php_argc + 3; argv = (char **) emalloc(argc * sizeof(char *)); argv[0] = estrdup("dummy"); argv[1] = estrdup("graph"); argv[2] = estrndup(file, file_len); for (i = 3; i < argc; i++) { zval **dataptr; if ( zend_hash_get_current_data(args_arr, (void *) &dataptr) == FAILURE ) continue; entry = *dataptr; if ( entry->type != IS_STRING ) convert_to_string(entry); argv[i] = estrdup(entry->value.str.val); if ( i < argc ) zend_hash_move_forward(args_arr); } optind = 0; opterr = 0; #if HAVE_RRD_12X if ( rrd_graph(argc-1, &argv[1], &calcpr, &xsize, &ysize, NULL, &ymin, &ymax) != FAILURE ) { #else if ( rrd_graph(argc-1, &argv[1], &calcpr, &xsize, &ysize) != FAILURE ) { #endif array_init(return_value); add_assoc_long(return_value, "xsize", xsize); add_assoc_long(return_value, "ysize", ysize); MAKE_STD_ZVAL(p_calcpr); array_init(p_calcpr); if (calcpr) { for (i = 0; calcpr[i]; i++) { add_next_index_string(p_calcpr, calcpr[i], 1); free(calcpr[i]); } free(calcpr); } zend_hash_update(return_value->value.ht, "calcpr", sizeof("calcpr"), (void *)&p_calcpr, sizeof(zval *), NULL); } else { RETVAL_FALSE; } for (i = 1; i < argc; i++) efree(argv[i]); efree(argv); return; } --- ## #21990 — D. Walsh — 2006-02-23T06:44:25+00:00 URL: https://externals.io/message/21983#21990 · In reply to: #21983 Anyone have any ideas or see the problem here??? > I had an issue with an extension that I previously posted to this > list and it was suggested I update to the newer API which might > provide a solution to the problem. > > Taking a somewhat safe approach I tackled converting the rrdtool > extension first since it was similar in functionality and protocol > to my ramdisk extension. > > Trying to convert to the new API wasn't as easy as it had been > suggested/reported. > > Steph Fox and I worked on it for several days before we finally got > it worked out. > > I tested the extension for the last week under Apache 1.3.33 and > found that the extension seemed to take less time to perform it's > functions which was well worth the effort to convert to the newer > API so thank you for the kick in this area. > > I then compiled for Apache 2 and found that I was still > experiencing the same issues so I'm sad to report that this did not > correct the problem. > > I realize that hearing "it doesn't work" or "it failed" isn't > descriptive so I'll try to provide a little more information on the > problem. > > Bear in mind that I have stepped back in time a little and have > gone with linking the RRDTool library in an attempt to remove as > many unknown variables from the equation as I possibly could and > allow testing with various version of the RRDTool library but the > RRDTool extension Tobias and I will be submitting for bundling with > PHP will not require linking to an external RRDTool library as it > will be entirely self contained however, the ability to link to an > external RRDTool library will be available provided we can get all > of our ducks in a row and satisfy the PHP license requirements > (which may already be the case). > > Building PHP for Apache 1.3, a php script calls the rrd_graph > function with a string (filename), an array (data to process) and a > long (the array count) and returns an array containing the > generated output file details. > > PHP seems to pass the variables to the linked library function > without any issues, generates the output file and returns an array > of the details with success. > > > Building PHP for Apache 2.0 and Apache 2.2, passing the same > information should yield the same results but it doesn't. > > The output file is never generated, the library complains that the > array being passed is incomplete and invalid and no array is returned. > > I've tried using both 1.0.x and 1.2.x versions of the RRDTool > library which resulted in the same issue so I've ruled out the > library function as the cause of the problem since they all worked > as expected when building PHP for Apache 1.3. > > Here's the entire rrd_graph function currently being used in the > testing phase, I've gone over the available API with Steph who > provided a lot of time, insight and assistance in helping me > convert to the new API so at this time I'm not sure what the issue > is or how to resolve it so if someone has ideas or sees a problem > I'd be most grateful to hear about it. > > ______________________________________________________________________ > _______________________________ > > PHP_FUNCTION(rrd_graph) > { > char *file; > zval *args, *entry, *p_calcpr; > HashTable *args_arr; > char **argv, **calcpr; > long php_argc, argc; > uint file_len; > int xsize, ysize, i = 0; > double ymin = 0.0, ymax = 0.0; > > > if ( rrd_test_error() ) > rrd_clear_error(); > > if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "sal", > &file, &file_len, &args, &php_argc) == FAILURE) > { > return; > } > if ( args->type != IS_ARRAY ) > { > php_error(E_WARNING, "2nd Variable passed to rrd_graph is not an > array!\n"); > RETURN_FALSE; > } > > args_arr = args->value.ht; > argc = php_argc + 3; > argv = (char **) emalloc(argc * sizeof(char *)); > > argv[0] = estrdup("dummy"); > argv[1] = estrdup("graph"); > argv[2] = estrndup(file, file_len); > > > for (i = 3; i < argc; i++) > { > zval **dataptr; > > if ( zend_hash_get_current_data(args_arr, (void *) &dataptr) == > FAILURE ) > continue; > > entry = *dataptr; > > if ( entry->type != IS_STRING ) > convert_to_string(entry); > > argv[i] = estrdup(entry->value.str.val); > > if ( i < argc ) > zend_hash_move_forward(args_arr); > } > > optind = 0; opterr = 0; > #if HAVE_RRD_12X > if ( rrd_graph(argc-1, &argv[1], &calcpr, &xsize, &ysize, NULL, > &ymin, &ymax) != FAILURE ) > { > #else > if ( rrd_graph(argc-1, &argv[1], &calcpr, &xsize, &ysize) != > FAILURE ) > { > #endif > array_init(return_value); > add_assoc_long(return_value, "xsize", xsize); > add_assoc_long(return_value, "ysize", ysize); > > MAKE_STD_ZVAL(p_calcpr); > array_init(p_calcpr); > > if (calcpr) > { > for (i = 0; calcpr[i]; i++) > { > add_next_index_string(p_calcpr, calcpr[i], 1); > free(calcpr[i]); > } > free(calcpr); > } > zend_hash_update(return_value->value.ht, "calcpr", sizeof > ("calcpr"), > (void *)&p_calcpr, sizeof(zval *), NULL); > } > else > { > RETVAL_FALSE; > } > for (i = 1; i < argc; i++) > efree(argv[i]); > > efree(argv); > return; > } --- ## #21993 — Wez Furlong — 2006-02-24T12:11:09+00:00 URL: https://externals.io/message/21983#21993 · In reply to: #21990 My suggestion is to download, compile and use valgrind and see what problems that highlights in your code. --Wez. > Anyone have any ideas or see the problem here??? > > > > > […] --- ## #22020 — D. Walsh — 2006-02-27T03:15:19+00:00 URL: https://externals.io/message/21983#22020 · In reply to: #21993 > My suggestion is to download, compile and use valgrind and see what > problems that highlights in your code. Since you are specifically directing me to do this I will attempt to get valgrind installed and working in Mac OSX, as soon as I have that done I'll update you so we can proceed further. -- Dale > --Wez. > > > > […] --- ## #22021 — Rasmus Lerdorf — 2006-02-27T03:17:33+00:00 URL: https://externals.io/message/21983#22021 · In reply to: #22020 D. Walsh wrote: > > > > > […] > > Since you are specifically directing me to do this I will attempt to get > valgrind installed and working in Mac OSX, as soon as I have that done > I'll update you so we can proceed further. When you manage that, please send me a copy of an OSX-PPC compatible Valgrind! I don't think you are going to have much luck with that. -Rasmus --- ## #22022 — D. Walsh — 2006-02-27T04:40:38+00:00 URL: https://externals.io/message/21983#22022 · In reply to: #22021 > D. Walsh wrote: > > […] > > When you manage that, please send me a copy of an OSX-PPC > compatible Valgrind! > > I don't think you are going to have much luck with that. I see what you mean, I'm looking into it now however I think the strict Linux kernel dependancy is going to be the big issue in preventing it from compiling, is there something else acceptable to valgrind that works in Mac OSX/Darwin??? > -Rasmus -- Dale --- ## #22028 — alpha@rrs@Nico Edtinger — 2006-02-27T11:38:59+00:00 URL: https://externals.io/message/21983#22028 · In reply to: #22022 Hi! Mac OS X has some tools for debugging and profiling. They may not be as easy to use as valgrind, but they still work. http:// kernelthread.com/mac/osx/tools.html is a good overview of the most important CLI tools (search for debug, profile, trace in the document). The same guy has a forum on his other page, http://www.osxbook.com/ forums/, where you could ask Amit if you need some additional help. b4n > I see what you mean, I'm looking into it now however I think the > strict Linux kernel dependancy is going to be the big issue in > preventing it from compiling, is there something else acceptable to > valgrind that works in Mac OSX/Darwin??? > > -- Dale --- ## #22031 — Marcus Bointon — 2006-02-27T13:23:44+00:00 URL: https://externals.io/message/21983#22031 · In reply to: #22021 > When you manage that, please send me a copy of an OSX-PPC > compatible Valgrind! Don't know if it helps, but kcachegrind works a treat on OS X. It's just had an update via fink too. Marcus -- Marcus Bointon Synchromedia Limited: Putting you in the picture marcus@synchromedia.co.uk | http://www.synchromedia.co.uk --- ## #22035 — Wez Furlong — 2006-02-28T13:35:35+00:00 URL: https://externals.io/message/21983#22035 · In reply to: #22020 If your code is portable, I'd suggest debugging it on linux. --Wez. > > > > > […] > > Since you are specifically directing me to do this I will attempt to > get valgrind installed and working in Mac OSX, as soon as I have that > done I'll update you so we can proceed further. > > -- Dale > > > […] --- ## #22045 — D. Walsh — 2006-03-01T10:44:03+00:00 URL: https://externals.io/message/21983#22045 · In reply to: #22021 > D. Walsh wrote: > > […] > > When you manage that, please send me a copy of an OSX-PPC > compatible Valgrind! > > I don't think you are going to have much luck with that. Well, I must admit, you were right, I spent a few days working on it and the Linux kernel dependancy isn't an easy one to to get around. I've also made some progress, I've been able to get the (updated API) source to work with apache 2.0.x and 2.2 and as noted in Apache 1.3.33, the new API seems to make the extension respond quicker. Unfortunately I've only been able to get it to work properly if PHP is built for Apache 2.x as an 'apxs2filter' so perhaps someone has an ideas or possible solution for this? > -Rasmus -- Dale