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]
