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 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: [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] To contact the list > administrators, e-mail: [EMAIL PROTECTED] > > > > > -- > 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] > > -- 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]