Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » ze1 question (bug 23132) »

ze1 question (bug 23132)

php.internals

George Schlossnagle

23 years ago
I'm trying to track down a ze1 bug for edin: http://bugs.php.net/bug.php?id=23132 What's happening is that under certain conditions (like the testcase in the bug) Variables passed by reference into a function are being reference counted in ZEND_RECV (correct), but not being dereferenced when the function ends and their copy-pointer falls out of scope. In the test case this is done in a loop, which eventually causes the zvals refcount to overflow causing it to be accidentally garbage collected, causing a segfault. I've found and witnessed all of the above, but I'm not sure where the variables should be deref'd when the function ends. Any pointers from anyone in the know?

Rob Richards

23 years ago
I am looking to use getter/setter functionality within classes in an extension. After going through the object_handler piece, it looks like the only way to implement it is by using a single function which then must handle performing the appropriate function based on the property that was passed in. The only examples I could see using this functionality were extensions which were working against external objects (such as the ones in the rpc extensions). Is this the only way to do this or are there any other calls that can be used (similar to the add_property_x calls but which would allow you to specify a function for the get/set)? If so, is it possible to use a hash table for each class which would have the property and a function so that when the property name is passed in to the _get/_set handler it can look up the property and then call the appropriate function? Now that being said how can a private hash be setup on a class basis and how is the memory destruction to be handled for a private hash? Last question concerns streams. How stable are streams at this point? Its been a while since I had seen talk about streams other than when they were first being introduced. We are possibly looking to implement some functionality using streams (not a priority in the extension at this point), but want to know wether it is something to consider or not. Thanks, Rob Richards

Wez Furlong

23 years ago
On Sat, 12 Apr 2003, Rob Richards wrote:
> If so, is it possible to use a hash table for each class which would have > the property and a function so that when the property name is passed in to > the _get/_set handler it can look up the property and then call the > appropriate function? > Now that being said how can a private hash be setup on a class basis and how > is the memory destruction to be handled for a private hash?
Look at ext/rpc, ext/adt and ext/mysqli.
> Last question concerns streams. How stable are streams at this point? Its > been a while since I had seen talk about streams other than when they were > first being introduced. We are possibly looking to implement some > functionality using streams (not a priority in the extension at this point), > but want to know wether it is something to consider or not.
Stable (despite some hiccups in 4.3.0). <plug> I recommend reading my articles in PHP Magazine http://php-mag.net if you are planning to develop your own streams. </plug> Also note that you should not use ANSI stdio within PHP if you want your extension to be portable; AT&T based libc (Solaris) has braindead limits on the number of files you can open, and that limit may have already been reached or exceeded even before PHP and the Zend Engine have been started to handle the request. --Wez.

George Schlossnagle

23 years ago
On Saturday, April 12, 2003, at 09:06 AM, Wez Furlong wrote:
> Also note that you should not use ANSI stdio within PHP if you want > your > extension to be portable; AT&T based libc (Solaris) has braindead > limits > on the number of files you can open, and that limit may have already > been reached or exceeded even before PHP and the Zend Engine have been > started to handle the request.
Not to sound like Sascha, but this shouldnt be an issue if you correctly configure your system. George

J Smith

23 years ago
The problems people are having with iPlanet/Solaris/php seem to be the result of incorrectly condfigured systems. (As mine was before upping the maximum number of opened files per process -- I'm clueless on Solaris, so sue me.) We've had a copy of our site running on Solaris 8 SPARC/iPlanet box now a week and haven't hit any of those weird file limits, so I'm starting to think that the problems in Solaris' stock libc are being overexaggerated. J George Schlossnagle wrote:

Wez Furlong

23 years ago
On the contrary, it's easy to underestimate the problem :) If you are using a stdio replacement, (such as sfio), then you are more-or-less safe from the problem. The problem is that the native libc will not allow file descriptors with a numerical value > 255, regardless of your per-process file descriptor limit. If you are running under a longer-lived SAPI, the server or previous requests may have already bumped your descriptor usage above this limit (each open socket and file descriptor adds to the total). This means that any fopen(), fdopen() or popen() calls can fail without good reason. So, my advice to Solaris users is to use sfio where possible, and to keep an eye out for the error message "too many open files"; when you see it, you can try tuning your MaxRequestsPerChild (or equivalent) configuration setting in your web server and lower it, if possible. --Wez. On Mon, 14 Apr 2003, Jay Smith wrote:

J Smith

23 years ago
I haven't done much testing yet, but our site is working fine. I've done a few tests on include and fopen and such (we can include 10,000 files without any problems and fopen ~1005 files after setting the max per-process file limit to 1024. Maybe it'll start messing up after I let the server run for a while longer, but so far, so good. Haven't tried sfio with the iPlanet module yet, but it seems to work with cli/cgi. I'll play with it a bit more and we'll see what happens. J Wez Furlong wrote:

George Schlossnagle

23 years ago
On Monday, April 14, 2003, at 12:09 PM, Wez Furlong wrote:
> On the contrary, it's easy to underestimate the problem :) > > If you are using a stdio replacement, (such as sfio), then you are > more-or-less safe from the problem. > > The problem is that the native libc will not allow file descriptors > with a numerical value > 255, regardless of your per-process file > descriptor limit.
I don't think this is true. #include "stdio.h" #include "fcntl.h" int main() { int i = 0; int fd = 0; while(1) { char path[11]; snprintf(path, 11, "/tmp/t/%d", i++); if((fd = open(path, O_RDWR|O_CREAT, 0)) < 0 ) { return; } printf("Opened fd: %d number %d\n", fd, i); } } created me 1021 fd's as a non-priv'd user on my Sol 2.6 system (with it's standard libc). The problem is with the stdio routines (fopen et. al.). As long as you don't use fopen you're set.

Wez Furlong

23 years ago
Thats right - I am talking about ANSI stdio; fopen() etc., not POSIX open(). --Wez. On Mon, 14 Apr 2003, George Schlossnagle wrote:

J Smith

23 years ago
Here's a test for those interested. Ran this on Solaris 8 SPARC. #include <stdio.h> #include <errno.h> int main () { FILE *fd; int i = 0; char filename[30]; while (1) { sprintf(filename, "tests/test%d.txt", i++); fd = fopen(filename, "r"); if (fd == NULL) { printf("died on %d, %d, %s\n", i, errno, strerror(errno)); exit(1); } } } Ran this through two tests. ulimit says the max for open files per process is 1024. Here's the results, first with the stock libraries, then with sfio: [jay@portabuddy jay]$ gcc -g test.c [jay@portabuddy jay]$ ./a.out died on 254, 24, Too many open files [jay@portabuddy jay]$ gcc -g test.c -L/export/home/jay/setup/sfio/lib -lstdio -lsfio [jay@portabuddy jay]$ ./a.out died on 1022, 24, Too many open files [jay@portabuddy jay]$ So sfio seems to be the way to go with php4 at the moment. For anybody who's having problems getting sfio to work with php4, just configure with LIBS set to "-L/path/to/sfio/lib -lstdio -lsfio". Just make sure stdio is there before sfio and you should be set. No need for weird includes or anything. J Wez Furlong wrote:

George Schlossnagle

23 years ago
On Monday, April 14, 2003, at 02:06 PM, Jay Smith wrote:
> > Here's a test for those interested. Ran this on Solaris 8 SPARC. > > #include <stdio.h> > #include <errno.h> > > int main () > { > FILE *fd; > int i = 0; > char filename[30]; > > while (1) { > sprintf(filename, "tests/test%d.txt", i++); > fd = fopen(filename, "r"); > if (fd == NULL) { > printf("died on %d, %d, %s\n", i, errno, strerror(errno)); > exit(1); > } > } > } > > Ran this through two tests. ulimit says the max for open files per > process > is 1024. Here's the results, first with the stock libraries, then with > sfio: > > [jay@portabuddy jay]$ gcc -g test.c > [jay@portabuddy jay]$ ./a.out > died on 254, 24, Too many open files > [jay@portabuddy jay]$ gcc -g test.c -L/export/home/jay/setup/sfio/lib > -lstdio -lsfio > [jay@portabuddy jay]$ ./a.out > died on 1022, 24, Too many open files > [jay@portabuddy jay]$ > > So sfio seems to be the way to go with php4 at the moment. > > For anybody who's having problems getting sfio to work with php4, just > configure with LIBS set to "-L/path/to/sfio/lib -lstdio -lsfio". Just > make > sure stdio is there before sfio and you should be set. No need for > weird > includes or anything.
Sure. The issue is that the stdio libraries (fopen, etc) dont support more than 256 open files. You can alos choose to use open et.al. A further complication is that errno is not correctly set when failing in this case on Solaris 7 and earlier. George

George Schlossnagle

23 years ago
On Monday, April 14, 2003, at 01:17 PM, Wez Furlong wrote:
> Thats right - I am talking about ANSI stdio; fopen() etc., not POSIX > open().
Any reason not to use the POSIX versions where they are available? George

Wez Furlong

23 years ago
PHP uses them where it can, however, the ZE 1.x requires the use of stdio for its scanners (ini files and scripts). ZE 2 does not have this dependency. --Wez. On Mon, 14 Apr 2003, George Schlossnagle wrote:

Uwe Schindler

23 years ago
Sorry that I wait so long in testing sfio on solaris 9, but after tomorrow I will have enough time (diploma exam...). What I can say about it: The current version of sfio is not compatible with Solaris 8/9: * Compiling fails because FILE_TAG is not only declared in stdio.h only, also in some other .h files (I think this is for faster preprocessing???) * Linking with -lstdio -lsfio only works if libstdio.a and libsfio.a are in the current directory (-L. instead of -L/path/to/libs), if not it fails (I do not know why, could be that -L. is used automatically as the first search path for libs, if use exact dir it is searched for at the end) When this problems are solved, I would prefer to make a switch --with-sfio into the configure script. I think I will check this during this week. If the linking problem is still there a method to fix this would be by copying the .a files befor make or in the configure script). The missing replacement header file problem can be fixed by one additional replacement for floating_point.h (this is the header file which has a duplicate definition of FILE_TAG). Uwe At 18:17 14.04.2003 +0100, Wez Furlong wrote:
>Thats right - I am talking about ANSI stdio; fopen() etc., not POSIX >open(). > >--Wez. > >On Mon, 14 Apr 2003, George Schlossnagle wrote: > > > > > On Monday, April 14, 2003, at 12:09 PM, Wez Furlong wrote: > > > > > On the contrary, it's easy to underestimate the problem :) > > > > > > If you are using a stdio replacement, (such as sfio), then you are > > > more-or-less safe from the problem. > > > > > > The problem is that the native libc will not allow file descriptors > > > with a numerical value > 255, regardless of your per-process file > > > descriptor limit. > > > > I don't think this is true. > > > > #include "stdio.h" > > #include "fcntl.h" > > > > int main() { > > int i = 0; > > int fd = 0; > > while(1) { > > char path[11]; > > snprintf(path, 11, "/tmp/t/%d", i++); > > if((fd = open(path, O_RDWR|O_CREAT, 0)) < 0 ) { > > return; > > } > > printf("Opened fd: %d number %d\n", fd, i); > > } > > } > > > > created me 1021 fd's as a non-priv'd user on my Sol 2.6 system (with > > it's standard libc). > > > > The problem is with the stdio routines (fopen et. al.). As long as you > > don't use fopen you're set. > > > > > > > > > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php
----- Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: uwe@thetaphi.de (private); info@schindlers-software.de (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen!

J Smith

23 years ago
I've got sfio working with php on Solaris 8 SPARC. Had some problems in the beginning, but it does seem to be working. (Well, it compiles and links fine, at least. They definitely aren't in the current directory when building php.) Try LIBS="-L/path/to/sfio/lib/ -lstdio -lsfio" ./configure ... Worked for me, anyway. J Uwe Schindler wrote:

Uwe Schindler

23 years ago
You have to use -lstdio-mt -lsfio-mt because you need a thread save implementation. It worked for me at the end, but first I had to fix the problems with _FILE_TAG. I wrote a bug report to AT&T and they confirmed it. The problem with linking could be another specific one. I will try it also under Solaris 9 for x86 in a vmware at my local computer, too. Uwe At 17:10 14.04.2003 -0400, Jay Smith wrote:
>I've got sfio working with php on Solaris 8 SPARC. Had some problems in the >beginning, but it does seem to be working. (Well, it compiles and links >fine, at least. They definitely aren't in the current directory when >building php.) > >Try > >LIBS="-L/path/to/sfio/lib/ -lstdio -lsfio" ./configure ... > >Worked for me, anyway. > >J > > >Uwe Schindler wrote: > > > Sorry that I wait so long in testing sfio on solaris 9, but after tomorrow > > I will have enough time (diploma exam...). What I can say about it: > > The current version of sfio is not compatible with Solaris 8/9: > > * Compiling fails because FILE_TAG is not only declared in stdio.h only, > > also in some other .h files (I think this is for faster preprocessing???) > > * Linking with -lstdio -lsfio only works if libstdio.a and libsfio.a are > > in the current directory (-L. instead of -L/path/to/libs), if not it fails > > (I do not know why, could be that -L. is used automatically as the first > > search path for libs, if use exact dir it is searched for at the end) > > > > When this problems are solved, I would prefer to make a switch --with-sfio > > into the configure script. I think I will check this during this week. If > > the linking problem is still there a method to fix this would be by > > copying the .a files befor make or in the configure script). The missing > > replacement header file problem can be fixed by one additional replacement > > for floating_point.h (this is the header file which has a duplicate > > definition of FILE_TAG). > > > > Uwe > > > > >-- >PHP Internals - PHP Runtime Development Mailing List >To unsubscribe, visit: http://www.php.net/unsub.php
----- Uwe Schindler Addr 1: Bamberger Str. 24a, D-96049 Bamberg Addr 2: Drausnickstr. 153, D-91052 Erlangen http://www.thetaphi.de - http:///www.schindlers-software.de eMails: uwe@thetaphi.de (private); info@schindlers-software.de (company) Tel./Fax: +49 700 PCLATEIN (+49 700 72528346) Schindlers Software - Home of Schindlers PC-LATEIN 3.10 DIE Software zum Lateinlernen!

J Smith

23 years ago
Didn't know iplanet was multithreaded. Guess I'll have to fix that. Good thing we don't use that solaris box for anything other than testing at the moment... J Uwe Schindler wrote: