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 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]
> 
> 


-- 
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]

Reply via email to