RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions
I *HAVE* searched the database and there have been similar problems, with the request to try the latest CVS and to produce a short script that duplicates the problem. Since I can't exactly put the CVS version onto a live website (and start having all sorts of other problems) and I can't duplicate the problem consistently on a non-active testing site, I don't really have anything else additional to offer except for Me Too!. My email already stated that I have tried to use --enable-debug and that I'm getting a segfault without any core file whatsoever. The last paragraph explains my attempts on using enable-debug. Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:04 PM To: [EMAIL PROTECTED]; Jaime Bozza Subject: [PHP] Re: PHP 4.1.0 and User-defined Sessions Search bug database to see if the same problem is reported or not. If you get segfault, buld PHP with --enable-debug and get core file. If it is new, get backtrace as described in bugs.php.net. Submit new bug report. If you found multiple issues, submit bug report separately. There are more comments following. Jaime Bozza wrote: Hello, I've run into a really intermittent and strange problem with PHP 4.1.0, and before I try and figure out how to send in a bug report that'll get ignored (because I don't have all the data that is expected), I thought I would try here to see if anyone else is having similar problems. Configuration: FreeBSD 4.4-STABLE, PostgreSQL 7.1.3, Apache 1.3.22, PHP 4.1.0. So far I don't have problem with Linux 2.4.4/PosrgreSql 7.1.3/Apache 1.3.22/PHP 4.1.0 or 4.2.0-dev I use PHP Sessions for large parts of our sites. I'm currently using the PostgreSQL Session Handler code from Jon Parise and it had been working pretty much perfectly under PHP 4.0.6. (The only issue was when multiple requests came in with the same session_id at the EXACT same time - AvantGo for instance - But I made some minor modifications to eliminate that problem) Once upgrading to 4.1.0, I started noticing Apache processes segfaulting left and right. (Signal 11's, with the occasional Signal 10) At first I started to think perhaps memory was bad on that particular system. I have 4 servers (running 3-5 separate Apache processes each) and each and every server was giving me the Signal 10/11's. I started looking into it further. I have an auto_prepend for my application code that defines the base session variables, config variables, includes the pgsql_session_handler file, etc. All the processing is handled here so that my other pages can just use an array that stores all the session data. That way I can pretty much ignore the backend in any of my application code. This setting is similar to mine also. Once I turned this code off, bingo! No more segfaults! So I started hacking out code there. If I kept all the startup code but eliminated the session commands, it still worked. As soon as I turned on the session (session_start/session_register), I'd get the segfaults again. If you could make *short* script that segfault, attach it to bug report. If I turned off the pgsql_session_handler and went back to files (the default), I didn't have any problems either. It was just a problem when I was using the pgsql_session_handler. I'm not sure what your session handler looks like, could try pgsql session handler that can be found at Zend.com's code exchange? So I then turned off session handling and built my own session functions (quickie, but basically emulate the session functions I needed) that called the SAME pgsql_session_handler code that was being used by PHP's internal functions. For the past hour I haven't had a single segfault on any of my servers. (Within 5 minutes of turning on the internal session routines, I would start getting segfaults every minute or so) One other thing I noticed was that I had compiled PHP with the mm shared memory library. Previous to 4.1.0, each Apache process had a size of around 64MB. (Without mm, the size was 4-5MB or so) Once installing 4.1.0, the size went up to 130MB for each process! Since I believe sessions utilize the mm library if it's available, I figure this may be one of the clues. (I never tried using the shared memory style of sessions, so I couldn't tell you if it would segfault there.) This is strange, mm session module allocates shared memory that is needed. (Description is not fully correct, but almost correct) Is anyone having any of these problems? Is anyone else using the internal PHP session support with their own session handler (under some of the same conditions I gave above) and having no problems with PHP4.1.0? Please let me know either way. BTW, I never get a core file. I've tried enable-debug to get the symbols in there, but without a core file I'm kind
Re: [PHP] Re: PHP 4.1.0 and User-defined Sessions
Jaime Bozza wrote: I *HAVE* searched the database and there have been similar problems, with the request to try the latest CVS and to produce a short script that duplicates the problem. Since I can't exactly put the CVS version onto a live website (and start having all sorts of other problems) and I can't duplicate the problem consistently on a non-active testing site, I don't really have anything else additional to offer except for Me Too!. My email already stated that I have tried to use --enable-debug and that I'm getting a segfault without any core file whatsoever. The last paragraph explains my attempts on using enable-debug. This is not practical, but you can try to run apache under gdb. If any segfault happens while you are running apache under gdb, you can get backtrace. BTW, did you try benchmarking tools like ab? You may be able to reproduce problem with benchmark tools. -- Yasuo Ohgaki Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:04 PM To: [EMAIL PROTECTED]; Jaime Bozza Subject: [PHP] Re: PHP 4.1.0 and User-defined Sessions Search bug database to see if the same problem is reported or not. If you get segfault, buld PHP with --enable-debug and get core file. If it is new, get backtrace as described in bugs.php.net. Submit new bug report. If you found multiple issues, submit bug report separately. There are more comments following. Jaime Bozza wrote: Hello, I've run into a really intermittent and strange problem with PHP 4.1.0, and before I try and figure out how to send in a bug report that'll get ignored (because I don't have all the data that is expected), I thought I would try here to see if anyone else is having similar problems. Configuration: FreeBSD 4.4-STABLE, PostgreSQL 7.1.3, Apache 1.3.22, PHP 4.1.0. So far I don't have problem with Linux 2.4.4/PosrgreSql 7.1.3/Apache 1.3.22/PHP 4.1.0 or 4.2.0-dev I use PHP Sessions for large parts of our sites. I'm currently using the PostgreSQL Session Handler code from Jon Parise and it had been working pretty much perfectly under PHP 4.0.6. (The only issue was when multiple requests came in with the same session_id at the EXACT same time - AvantGo for instance - But I made some minor modifications to eliminate that problem) Once upgrading to 4.1.0, I started noticing Apache processes segfaulting left and right. (Signal 11's, with the occasional Signal 10) At first I started to think perhaps memory was bad on that particular system. I have 4 servers (running 3-5 separate Apache processes each) and each and every server was giving me the Signal 10/11's. I started looking into it further. I have an auto_prepend for my application code that defines the base session variables, config variables, includes the pgsql_session_handler file, etc. All the processing is handled here so that my other pages can just use an array that stores all the session data. That way I can pretty much ignore the backend in any of my application code. This setting is similar to mine also. Once I turned this code off, bingo! No more segfaults! So I started hacking out code there. If I kept all the startup code but eliminated the session commands, it still worked. As soon as I turned on the session (session_start/session_register), I'd get the segfaults again. If you could make *short* script that segfault, attach it to bug report. If I turned off the pgsql_session_handler and went back to files (the default), I didn't have any problems either. It was just a problem when I was using the pgsql_session_handler. I'm not sure what your session handler looks like, could try pgsql session handler that can be found at Zend.com's code exchange? So I then turned off session handling and built my own session functions (quickie, but basically emulate the session functions I needed) that called the SAME pgsql_session_handler code that was being used by PHP's internal functions. For the past hour I haven't had a single segfault on any of my servers. (Within 5 minutes of turning on the internal session routines, I would start getting segfaults every minute or so) One other thing I noticed was that I had compiled PHP with the mm shared memory library. Previous to 4.1.0, each Apache process had a size of around 64MB. (Without mm, the size was 4-5MB or so) Once installing 4.1.0, the size went up to 130MB for each process! Since I believe sessions utilize the mm library if it's available, I figure this may be one of the clues. (I never tried using the shared memory style of sessions, so I couldn't tell you if it would segfault there.) This is strange, mm session module allocates shared memory that is needed. (Description is not fully correct, but almost correct) Is anyone having any of these problems? Is anyone else
RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions
I've been trying to work something up running httpd -X, unfortunately, single user access doesn't seem to help. As near as I can tell, it happens only with concurrent access. Perhaps some type of memory lock or something. I no longer have --with-mm, so it's not trying to use that type of shared memory. Can gdb help with running httpd *without* the -X? I've tried ab, but I think I'm going to try again (running ab multiple times on different pages to try and simulate real world access) and see if I can get anything to come up there. Again, concurrent access seems to be the key as I have been unable to get Apache(PHP) to segfault on a test server with single access only. I took a look at the PostgreSQL session code on Zend (which I believe you've written)... The one's I'm using are quite a bit similar, though yours track counts and such. The core reading/writing is similar, except for the following: The Zend version will still load a session up even if the maxlifetime has been exceeded. Since gc isn't called EVERY time (unless probability is 100), occasionally there could be the possibility of stale session data being loaded up. This is a simple one to fix, but important for me. I notice that you have the row locking in the SELECT for the session_read. Will this cause PostgreSQL to deny read access for another concurrent connection (with the same session_id), or will that second connection wait until the first is done? I guess I'll have to test that out. If you want, I can switch over to your code and to prove it's not the session_handler code itself. How busy are the sites you maintain that use the session handler code? (In requests per minute, etc.) I noticed your comment on the mm code. Like I said, I was a bit confused on that as well. I can certainly write a bug report up for that, but I don't know if you'd classify that as a bug. Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 1:01 PM To: Jaime Bozza Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP 4.1.0 and User-defined Sessions Jaime Bozza wrote: I *HAVE* searched the database and there have been similar problems, with the request to try the latest CVS and to produce a short script that duplicates the problem. Since I can't exactly put the CVS version onto a live website (and start having all sorts of other problems) and I can't duplicate the problem consistently on a non-active testing site, I don't really have anything else additional to offer except for Me Too!. My email already stated that I have tried to use --enable-debug and that I'm getting a segfault without any core file whatsoever. The last paragraph explains my attempts on using enable-debug. This is not practical, but you can try to run apache under gdb. If any segfault happens while you are running apache under gdb, you can get backtrace. BTW, did you try benchmarking tools like ab? You may be able to reproduce problem with benchmark tools. -- Yasuo Ohgaki Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:04 PM To: [EMAIL PROTECTED]; Jaime Bozza Subject: [PHP] Re: PHP 4.1.0 and User-defined Sessions Search bug database to see if the same problem is reported or not. If you get segfault, buld PHP with --enable-debug and get core file. If it is new, get backtrace as described in bugs.php.net. Submit new bug report. If you found multiple issues, submit bug report separately. There are more comments following. Jaime Bozza wrote: Hello, I've run into a really intermittent and strange problem with PHP 4.1.0, and before I try and figure out how to send in a bug report that'll get ignored (because I don't have all the data that is expected), I thought I would try here to see if anyone else is having similar problems. Configuration: FreeBSD 4.4-STABLE, PostgreSQL 7.1.3, Apache 1.3.22, PHP 4.1.0. So far I don't have problem with Linux 2.4.4/PosrgreSql 7.1.3/Apache 1.3.22/PHP 4.1.0 or 4.2.0-dev I use PHP Sessions for large parts of our sites. I'm currently using the PostgreSQL Session Handler code from Jon Parise and it had been working pretty much perfectly under PHP 4.0.6. (The only issue was when multiple requests came in with the same session_id at the EXACT same time - AvantGo for instance - But I made some minor modifications to eliminate that problem) Once upgrading to 4.1.0, I started noticing Apache processes segfaulting left and right. (Signal 11's, with the occasional Signal 10) At first I started to think perhaps memory was bad on that particular system. I have 4 servers (running 3-5 separate Apache processes each) and each and every server was giving me the Signal 10/11's. I started looking into it further. I have an auto_prepend for my application code that defines the base session variables, config variables
RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions
FWIW, and I don't have time to try to debug this right now, so I've rolled back to 4.0.6 on my dev server (never upgraded production), I too am seeing seemingly random segfaults (Sig 11) from php 4.1.0 + Apache 1.3.22. All is well in 4.0.6 (and 1.3.22). I, too, am using a database bound custom session handler - specifically, the one for mysql by Yin Zhang (session_mysql.php), and my site(s) make heavy use of sessions. When I free up a bit, I'll try running some tests (disabling sessions, etc) to see if I can get to the bottom of this. Here's my config line: ./configure --with-mysql=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --with-pdflib=/usr/local \ --with-ttf \ --with-gd \ --enable-trans-sid \ --with-curl \ --with-openssl \ --enable-sysvsem \ --enable-sysvshm \ --with-zlib Redhat 7.1 + kernel 2.4.16. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. net] On Behalf Of Jaime Bozza Sent: Thursday, December 13, 2001 2:36 PM To: 'Yasuo Ohgaki' Cc: [EMAIL PROTECTED] Subject: RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions I've been trying to work something up running httpd -X, unfortunately, single user access doesn't seem to help. As near as I can tell, it happens only with concurrent access. Perhaps some type of memory lock or something. I no longer have --with-mm, so it's not trying to use that type of shared memory. Can gdb help with running httpd *without* the -X? I've tried ab, but I think I'm going to try again (running ab multiple times on different pages to try and simulate real world access) and see if I can get anything to come up there. Again, concurrent access seems to be the key as I have been unable to get Apache(PHP) to segfault on a test server with single access only. I took a look at the PostgreSQL session code on Zend (which I believe you've written)... The one's I'm using are quite a bit similar, though yours track counts and such. The core reading/writing is similar, except for the following: The Zend version will still load a session up even if the maxlifetime has been exceeded. Since gc isn't called EVERY time (unless probability is 100), occasionally there could be the possibility of stale session data being loaded up. This is a simple one to fix, but important for me. I notice that you have the row locking in the SELECT for the session_read. Will this cause PostgreSQL to deny read access for another concurrent connection (with the same session_id), or will that second connection wait until the first is done? I guess I'll have to test that out. If you want, I can switch over to your code and to prove it's not the session_handler code itself. How busy are the sites you maintain that use the session handler code? (In requests per minute, etc.) I noticed your comment on the mm code. Like I said, I was a bit confused on that as well. I can certainly write a bug report up for that, but I don't know if you'd classify that as a bug. Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 1:01 PM To: Jaime Bozza Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP 4.1.0 and User-defined Sessions Jaime Bozza wrote: I *HAVE* searched the database and there have been similar problems, with the request to try the latest CVS and to produce a short script that duplicates the problem. Since I can't exactly put the CVS version onto a live website (and start having all sorts of other problems) and I can't duplicate the problem consistently on a non-active testing site, I don't really have anything else additional to offer except for Me Too!. My email already stated that I have tried to use --enable-debug and that I'm getting a segfault without any core file whatsoever. The last paragraph explains my attempts on using enable-debug. This is not practical, but you can try to run apache under gdb. If any segfault happens while you are running apache under gdb, you can get backtrace. BTW, did you try benchmarking tools like ab? You may be able to reproduce problem with benchmark tools. -- Yasuo Ohgaki Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 12, 2001 9:04 PM To: [EMAIL PROTECTED]; Jaime Bozza Subject: [PHP] Re: PHP 4.1.0 and User-defined Sessions Search bug database to see if the same problem is reported or not. If you get segfault, buld PHP with --enable-debug and get core file. If it is new, get backtrace as described in bugs.php.net. Submit new bug report. If you found multiple issues, submit bug report separately. There are more
RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions
Also, I saw the faults with little to no load on the server. I.e. just me banging on it. The faults are seemingly random, although I was able to duplicate failing test cases with some consistency. More on this in a day or two. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. net] On Behalf Of Alok K. Dhir Sent: Thursday, December 13, 2001 2:49 PM To: 'Jaime Bozza'; 'Yasuo Ohgaki' Cc: [EMAIL PROTECTED] Subject: RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions FWIW, and I don't have time to try to debug this right now, so I've rolled back to 4.0.6 on my dev server (never upgraded production), I too am seeing seemingly random segfaults (Sig 11) from php 4.1.0 + Apache 1.3.22. All is well in 4.0.6 (and 1.3.22). I, too, am using a database bound custom session handler - specifically, the one for mysql by Yin Zhang (session_mysql.php), and my site(s) make heavy use of sessions. When I free up a bit, I'll try running some tests (disabling sessions, etc) to see if I can get to the bottom of this. Here's my config line: ./configure --with-mysql=/usr/local \ --with-apxs=/usr/local/apache/bin/apxs \ --with-pdflib=/usr/local \ --with-ttf \ --with-gd \ --enable-trans-sid \ --with-curl \ --with-openssl \ --enable-sysvsem \ --enable-sysvshm \ --with-zlib Redhat 7.1 + kernel 2.4.16. Regards -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]. net] On Behalf Of Jaime Bozza Sent: Thursday, December 13, 2001 2:36 PM To: 'Yasuo Ohgaki' Cc: [EMAIL PROTECTED] Subject: RE: [PHP] Re: PHP 4.1.0 and User-defined Sessions I've been trying to work something up running httpd -X, unfortunately, single user access doesn't seem to help. As near as I can tell, it happens only with concurrent access. Perhaps some type of memory lock or something. I no longer have --with-mm, so it's not trying to use that type of shared memory. Can gdb help with running httpd *without* the -X? I've tried ab, but I think I'm going to try again (running ab multiple times on different pages to try and simulate real world access) and see if I can get anything to come up there. Again, concurrent access seems to be the key as I have been unable to get Apache(PHP) to segfault on a test server with single access only. I took a look at the PostgreSQL session code on Zend (which I believe you've written)... The one's I'm using are quite a bit similar, though yours track counts and such. The core reading/writing is similar, except for the following: The Zend version will still load a session up even if the maxlifetime has been exceeded. Since gc isn't called EVERY time (unless probability is 100), occasionally there could be the possibility of stale session data being loaded up. This is a simple one to fix, but important for me. I notice that you have the row locking in the SELECT for the session_read. Will this cause PostgreSQL to deny read access for another concurrent connection (with the same session_id), or will that second connection wait until the first is done? I guess I'll have to test that out. If you want, I can switch over to your code and to prove it's not the session_handler code itself. How busy are the sites you maintain that use the session handler code? (In requests per minute, etc.) I noticed your comment on the mm code. Like I said, I was a bit confused on that as well. I can certainly write a bug report up for that, but I don't know if you'd classify that as a bug. Jaime Bozza -Original Message- From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 1:01 PM To: Jaime Bozza Cc: [EMAIL PROTECTED] Subject: Re: [PHP] Re: PHP 4.1.0 and User-defined Sessions Jaime Bozza wrote: I *HAVE* searched the database and there have been similar problems, with the request to try the latest CVS and to produce a short script that duplicates the problem. Since I can't exactly put the CVS version onto a live website (and start having all sorts of other problems) and I can't duplicate the problem consistently on a non-active testing site, I don't really have anything else additional to offer except for Me Too!. My email already stated that I have tried to use --enable-debug and that I'm getting a segfault without any core file whatsoever. The last paragraph explains my attempts on using enable-debug. This is not practical, but you can try to run apache under gdb. If any segfault happens while you are running apache under gdb, you can get backtrace. BTW, did you try benchmarking tools like ab? You may be able to reproduce problem
Re: [PHP] Re: PHP 4.1.0 and User-defined Sessions
Alok K. Dhir wrote: Also, I saw the faults with little to no load on the server. I.e. just me banging on it. The faults are seemingly random, although I was able to duplicate failing test cases with some consistency. More on this in a day or two. Unless you provide meaningfull backtrace, it's impossible to fix. Anyway, don't try running httpd under gdb without -X Read the following link for getting backtrace. You may already know, but your server admin set limit on your machine. http://bugs.php.net/bugs-generating-backtrace.php -- Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
