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: > php-general-return-77660-adhir=govshops.com@lists.php.net > [mailto:php-general-return-77660-adhir=govshops.com@lists.php. > net] On Behalf Of Alok K. Dhir > Sent: Thursday, December 13, 2001 2:49 PM > To: 'Jaime Bozza'; 'Yasuo Ohgaki' > Cc: php-general@lists.php.net > 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: > > php-general-return-77651-adhir=govshops.com@lists.php.net > > [mailto:php-general-return-77651-adhir=govshops.com@lists.php. > > net] On Behalf Of Jaime Bozza > > Sent: Thursday, December 13, 2001 2:36 PM > > To: 'Yasuo Ohgaki' > > Cc: php-general@lists.php.net > > 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:yasuo_ohgaki@yahoo.com] > > Sent: Thursday, December 13, 2001 1:01 PM > > To: Jaime Bozza > > Cc: php-general@lists.php.net > > 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:yasuo_ohgaki@yahoo.com] > > > Sent: Wednesday, December 12, 2001 9:04 PM > > > To: php-general@lists.php.net; 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 of out > > of luck on > > >>tracing. All I can tell you now is that using user-defined > > handlers > > >>for sessions started causing me lots of problems. (As near > > as I can > > >>tell, you need to have some sort of a decent load on your > servers - > > >>Single client access didn't ever seem to allow me to force the > > >>crashes) > > >> > > >> > > > > > > > > > You can run httpd under gdb and can take backtrace. Try. > > > > > > > > > > > > > > -- > > 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: php-general-unsubscribe@lists.php.net > > For additional commands, e-mail: > > php-general-help@lists.php.net To contact the list > > administrators, e-mail: php-list-admin@lists.php.net > > > > > > > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > > For additional commands, e-mail: > > php-general-help@lists.php.net To contact the list > > administrators, e-mail: php-list-admin@lists.php.net > > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, e-mail: php-general-unsubscribe@lists.php.net > For additional commands, e-mail: > php-general-help@lists.php.net To contact the list > administrators, e-mail: php-list-admin@lists.php.net > >