php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #32974 Forked socket server segfaults after high connection volume
Submitted: 2005-05-07 10:27 UTC Modified: 2005-05-07 17:01 UTC
From: jim_keller at centerfuse dot net Assigned:
Status: Closed Package: Reproducible crash
PHP Version: 4.3.11 OS: FreeBSD 4.10
Private report: No CVE-ID:
 [2005-05-07 10:27 UTC] jim_keller at centerfuse dot net

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2005-05-07 15:00 UTC] wez@php.net
What's happening here is that PHP is in the middle of allocating some memory when SIGCHLD is delivered.  The pcntl signal handler then allocates some memory.
The fbsd malloc() is not re-entrant so emits the "in malloc warning: recursive call" and fails the memory allocation.
Normally, PHP allocates all memory via emalloc(), which will abort the PHP request when memory allocation fails, but for some reason, the person that wrote pcntl decided to use a persistent linked list that calls malloc direct.

So, what we've got here is a triple bug:

- pcntl should not malloc inside a signal handler
- pcntl should not use a persistent llist
- zend llist code should check the pemalloc return value


 [2005-05-07 17:01 UTC] wez@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Grab the next 4.3.x snapshot from http://snaps.php.net to try it out.

I fixed the problem by pre-allocating records for the signal queue.  There is a limit of 32 pending signals in the current implementation; if more than 32 signals are delivered before the tick handler can dispatch them, those signals will be ignored.
 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Fri Apr 18 03:02:48 2014 UTC