#32144 [Opn]: sqlite extension causes crash at PHP startup
ID: 32144
User updated by: ian at snork dot net
Reported By: ian at snork dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Debian sarge (i386)
PHP Version: 5CVS-2005-03-01 (dev)
Assigned To: helly
New Comment:
Both SPL and SQLite were built statically into the PHP
binary. I was using an unpatched daily snapshot (from
http://snaps.php.net/php5-latest.tar.bz2). The ./configure
line was:
./configure --without-mime-magic --enable-memory-limit
--disable-debug --with-layout=GNU
--with-pear=/usr/share/php --enable-calendar
--enable-sysvsem --enable-sysvshm --enable-sysvmsg
--enable-track-vars --enable-trans-sid --enable-bcmath
--with-bz2 --enable-ctype --with-db4 --with-iconv
--enable-exif --enable-filepro --enable-ftp --with-gettext
--enable-mbstring --with-pcre-regex=/usr --enable-shmop
--enable-sockets --enable-wddx --disable-xml
--with-expat-dir=/usr --with-xmlrpc --enable-yp
--with-zlib --with-pgsql=/usr --with-kerberos
--with-openssl=/usr --with-exec-dir=/usr/lib/php5/libexec
--prefix=/usr --with-apxs2=/usr/bin/apxs2 --with-regex=php
--with-config-file-path=/etc/php5/apache2 --disable-rpath
--with-curl=/usr --with-dom=/usr --with-dom-xslt=/usr
--with-dom-exslt=/usr --with-zlib-dir=/usr --with-gd=/usr
--enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-png-dir=/usr
--with-freetype-dir=/usr --with-imap=/usr --with-imap-ssl
--with-mcal=/usr --with-mhash=/usr --without-mm
--with-mysql=/usr --with-mysqli=/usr/bin/mysql_config
--with-unixODBC=/usr --enable-xslt=/usr
--with-xslt-sablot=/usr --with-snmp=/usr
--without-sybase-ct --with-ttf=/usr --with-t1lib=/usr
--without-custom-odbc --without-odbc --without-unixODBC
--without-iodbc --with-sqlite=/usr
And here's how they're ordered in the snapshot sources:
zend_module_entry *php_builtin_extensions[] = {
phpext_xmlrpc_ptr,
phpext_xml_ptr,
phpext_wddx_ptr,
phpext_tokenizer_ptr,
phpext_sysvshm_ptr,
phpext_sysvsem_ptr,
phpext_sysvmsg_ptr,
phpext_standard_ptr,
phpext_sqlite_ptr,
phpext_spl_ptr,
phpext_sockets_ptr,
phpext_snmp_ptr,
phpext_simplexml_ptr,
phpext_shmop_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pgsql_ptr,
phpext_pcre_ptr,
phpext_mysqli_ptr,
phpext_mysql_ptr,
phpext_mhash_ptr,
phpext_mbstring_ptr,
phpext_imap_ptr,
phpext_iconv_ptr,
phpext_gettext_ptr,
phpext_gd_ptr,
phpext_ftp_ptr,
phpext_filepro_ptr,
phpext_exif_ptr,
phpext_dom_ptr,
phpext_dba_ptr,
phpext_curl_ptr,
phpext_ctype_ptr,
phpext_calendar_ptr,
phpext_bz2_ptr,
phpext_bcmath_ptr,
phpext_zlib_ptr,
phpext_openssl_ptr,
phpext_libxml_ptr,
};
Without the patch I submitted, moving phpext_spl_ptr back
or forward in that list did prevent PHP from segfaulting.
After doubled-checking with GDB, it appeared that the SPL
startup function (zm_startup_spl) was not being called at
all.
So, I stuck a manual call to PHP_MINIT(spl) in
basic_functions.c because it seemed the most logical place
for this.
Previous Comments:
[2005-03-01 10:27:10] [EMAIL PROTECTED]
What is the configure line used? Especially i am interested if spl or
sqlite are build shared. And is this a clean cvs checkout or patched
somewhere? The reason i ask is that for your problem we have a
mechanismn in place already.
Also what is the order of 'phpext_spl_ptr' and
'phpext_sqlite_ptr' in main/internal_functions_*.c's
'php_builtin_extensions' array?
--------------------
[2005-03-01 09:28:29] ian at snork dot net
Description:
A PHP build with --with-spl and --with-sqlite will
segfault at startup in all SAPIs because the SPL extension
is not initialized at all.
The following patch appears to fix the problem:
--- php5-200503010530.orig/ext/standard/basic_functions.c
2005-01-18 11:30:05.0 +
+++ php5-200503010530/ext/standard/basic_functions.c
2005-03-01 08:03:14.578643275 +
@@ -1094,6 +1094,9 @@
PHP_MINIT(syslog)(INIT_FUNC_ARGS_PASSTHRU);
#endif
PHP_MINIT(array)(INIT_FUNC_ARGS_PASSTHRU);
+#ifdef HAVE_SPL
+ PHP_MINIT(spl)(INIT_FUN
#32144 [Opn]: sqlite extension causes crash at PHP startup
ID: 32144
User updated by: ian at snork dot net
Reported By: ian at snork dot net
Status: Open
Bug Type: Reproducible crash
Operating System: Debian sarge (i386)
PHP Version: 5CVS-2005-03-01 (dev)
Assigned To: helly
New Comment:
Oops -- I meant to say:
Moving phpext_sqlite_ptr and phpext_spl_ptr around in that
list did _not_ prevent a segfault.
Sorry. :)
Previous Comments:
[2005-03-01 11:37:42] ian at snork dot net
Both SPL and SQLite were built statically into the PHP
binary. I was using an unpatched daily snapshot (from
http://snaps.php.net/php5-latest.tar.bz2). The ./configure
line was:
./configure --without-mime-magic --enable-memory-limit
--disable-debug --with-layout=GNU
--with-pear=/usr/share/php --enable-calendar
--enable-sysvsem --enable-sysvshm --enable-sysvmsg
--enable-track-vars --enable-trans-sid --enable-bcmath
--with-bz2 --enable-ctype --with-db4 --with-iconv
--enable-exif --enable-filepro --enable-ftp --with-gettext
--enable-mbstring --with-pcre-regex=/usr --enable-shmop
--enable-sockets --enable-wddx --disable-xml
--with-expat-dir=/usr --with-xmlrpc --enable-yp
--with-zlib --with-pgsql=/usr --with-kerberos
--with-openssl=/usr --with-exec-dir=/usr/lib/php5/libexec
--prefix=/usr --with-apxs2=/usr/bin/apxs2 --with-regex=php
--with-config-file-path=/etc/php5/apache2 --disable-rpath
--with-curl=/usr --with-dom=/usr --with-dom-xslt=/usr
--with-dom-exslt=/usr --with-zlib-dir=/usr --with-gd=/usr
--enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-png-dir=/usr
--with-freetype-dir=/usr --with-imap=/usr --with-imap-ssl
--with-mcal=/usr --with-mhash=/usr --without-mm
--with-mysql=/usr --with-mysqli=/usr/bin/mysql_config
--with-unixODBC=/usr --enable-xslt=/usr
--with-xslt-sablot=/usr --with-snmp=/usr
--without-sybase-ct --with-ttf=/usr --with-t1lib=/usr
--without-custom-odbc --without-odbc --without-unixODBC
--without-iodbc --with-sqlite=/usr
And here's how they're ordered in the snapshot sources:
zend_module_entry *php_builtin_extensions[] = {
phpext_xmlrpc_ptr,
phpext_xml_ptr,
phpext_wddx_ptr,
phpext_tokenizer_ptr,
phpext_sysvshm_ptr,
phpext_sysvsem_ptr,
phpext_sysvmsg_ptr,
phpext_standard_ptr,
phpext_sqlite_ptr,
phpext_spl_ptr,
phpext_sockets_ptr,
phpext_snmp_ptr,
phpext_simplexml_ptr,
phpext_shmop_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pgsql_ptr,
phpext_pcre_ptr,
phpext_mysqli_ptr,
phpext_mysql_ptr,
phpext_mhash_ptr,
phpext_mbstring_ptr,
phpext_imap_ptr,
phpext_iconv_ptr,
phpext_gettext_ptr,
phpext_gd_ptr,
phpext_ftp_ptr,
phpext_filepro_ptr,
phpext_exif_ptr,
phpext_dom_ptr,
phpext_dba_ptr,
phpext_curl_ptr,
phpext_ctype_ptr,
phpext_calendar_ptr,
phpext_bz2_ptr,
phpext_bcmath_ptr,
phpext_zlib_ptr,
phpext_openssl_ptr,
phpext_libxml_ptr,
};
Without the patch I submitted, moving phpext_spl_ptr back
or forward in that list did prevent PHP from segfaulting.
After doubled-checking with GDB, it appeared that the SPL
startup function (zm_startup_spl) was not being called at
all.
So, I stuck a manual call to PHP_MINIT(spl) in
basic_functions.c because it seemed the most logical place
for this.
[2005-03-01 10:27:10] [EMAIL PROTECTED]
What is the configure line used? Especially i am interested if spl or
sqlite are build shared. And is this a clean cvs checkout or patched
somewhere? The reason i ask is that for your problem we have a
mechanismn in place already.
Also what is the order of 'phpext_spl_ptr' and
'phpext_sqlite_ptr' in main/internal_functions_*.c's
'php_builtin_extensions' array?
--------------------
[2005-03-01 09:28:29] ian at snork dot net
Description:
A PHP build with --with-spl and --with-sqlite will
segfault at startup in all SAPIs because the SPL extension
is not initialized at all.
The following patch appears to fix the problem:
--- php5-200503010530.orig/ext/standard/basic_functions.c
2005-01-18 11:30:05.0 +
+++ php5-200503010530/ext/st
#31363 [Fbk->Opn]: Non-blocking flock() broken
ID: 31363
User updated by: ian at snork dot net
Reported By: ian at snork dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Debian woody (i386)
PHP Version: 5CVS-2005-03-09
New Comment:
My apologies -- I posted just before your message from
bugs.php.net arrived. :)
http://www.snork.net/flock.diff
Previous Comments:
[2005-04-05 18:01:34] [EMAIL PROTECTED]
The URL to the patch would be much better.
[2005-04-05 17:59:11] ian at snork dot net
Aw, shucks. It's been word-wrapped.
Oh well -- send mail if you need an unmolested copy of the
patch. :)
[2005-04-05 17:57:55] [EMAIL PROTECTED]
Please, generate diffs with `diff -upd` and put them somewhere in the
Net.
Thanks you.
[2005-04-05 17:53:57] ian at snork dot net
The cause looks to be two separate bugs; here's a patch to
fix both.
*** php5-200504050030.orig/ext/standard/file.c Sun Mar 27
16:30:05 2005
--- php5-200504050030/ext/standard/file.c Tue Apr 5
15:26:08 2005
***
*** 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (!php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_TRUE;
}
! RETURN_FALSE;
}
/* }}} */
--- 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_FALSE;
}
! RETURN_TRUE;
}
/* }}} */
*** php5-200504050030.orig/main/streams/plain_wrapper.c
Thu Oct 28 06:35:19 2004
--- php5-200504050030/main/streams/plain_wrapper.c
Tue Apr 5 15:45:51 2005
***
*** 578,584
return 0;
}
! if (!flock(fd, value) || (errno ==
EWOULDBLOCK && value & LOCK_NB)) {
data->lock_flag = value;
return 0;
} else {
--- 578,584
return 0;
}
! if (!flock(fd, value)) {
data->lock_flag = value;
return 0;
} else {
[2005-04-05 01:55:32] maurice at gitaar dot net
I had the same problem. It seems that errno is not reset to zero in the
flock implementation. Therefore the last errno will be used. In case no
other errno-modifying call is made before retrying the flock() call,
the call will conclude in an EWOULDBLOCK situation (my conclusion after
a very quick scan of the code).
Looking with truss on Solaris to the process shows that the first fcntl
call (during which I have already locked the file) returns an EAGAIN
error, meaning that the file was already locked. The second fnctl call
(on the now unlocked file) does not return an error. So the call is
successfull. But the call from the php code does set the $wouldblock
parameter to a true value.
For me a workaround for now is something like this (no error checking
on flock and a bit of pseudo-coded, but the workaround is the important
part):
for (;;)
{
flock($fd, LOCK_EX|LOCK_NB, $wouldblock);
if (! $wouldblock) break;
fopen("/this/is/no/real/file", "r");
}
The fopen() call sets errno to the file not found error, which makes
the flock() call act like the first time it is called. This is not
great coding, but it does work for me till a real fix is implemented in
PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/31363
--
Edit this bug report at http://bugs.php.net/?id=31363&edit=1
#31363 [Fbk->Opn]: Non-blocking flock() broken
ID: 31363
User updated by: ian at snork dot net
Reported By: ian at snork dot net
-Status: Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Debian woody (i386)
PHP Version: 5CVS-2005-03-09
New Comment:
Aw, shucks. It's been word-wrapped.
Oh well -- send mail if you need an unmolested copy of the
patch. :)
Previous Comments:
[2005-04-05 17:57:55] [EMAIL PROTECTED]
Please, generate diffs with `diff -upd` and put them somewhere in the
Net.
Thanks you.
[2005-04-05 17:53:57] ian at snork dot net
The cause looks to be two separate bugs; here's a patch to
fix both.
*** php5-200504050030.orig/ext/standard/file.c Sun Mar 27
16:30:05 2005
--- php5-200504050030/ext/standard/file.c Tue Apr 5
15:26:08 2005
***
*** 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (!php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_TRUE;
}
! RETURN_FALSE;
}
/* }}} */
--- 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_FALSE;
}
! RETURN_TRUE;
}
/* }}} */
*** php5-200504050030.orig/main/streams/plain_wrapper.c
Thu Oct 28 06:35:19 2004
--- php5-200504050030/main/streams/plain_wrapper.c
Tue Apr 5 15:45:51 2005
***
*** 578,584
return 0;
}
! if (!flock(fd, value) || (errno ==
EWOULDBLOCK && value & LOCK_NB)) {
data->lock_flag = value;
return 0;
} else {
--- 578,584
return 0;
}
! if (!flock(fd, value)) {
data->lock_flag = value;
return 0;
} else {
[2005-04-05 01:55:32] maurice at gitaar dot net
I had the same problem. It seems that errno is not reset to zero in the
flock implementation. Therefore the last errno will be used. In case no
other errno-modifying call is made before retrying the flock() call,
the call will conclude in an EWOULDBLOCK situation (my conclusion after
a very quick scan of the code).
Looking with truss on Solaris to the process shows that the first fcntl
call (during which I have already locked the file) returns an EAGAIN
error, meaning that the file was already locked. The second fnctl call
(on the now unlocked file) does not return an error. So the call is
successfull. But the call from the php code does set the $wouldblock
parameter to a true value.
For me a workaround for now is something like this (no error checking
on flock and a bit of pseudo-coded, but the workaround is the important
part):
for (;;)
{
flock($fd, LOCK_EX|LOCK_NB, $wouldblock);
if (! $wouldblock) break;
fopen("/this/is/no/real/file", "r");
}
The fopen() call sets errno to the file not found error, which makes
the flock() call act like the first time it is called. This is not
great coding, but it does work for me till a real fix is implemented in
PHP.
[2005-04-01 14:42:19] maka3d at yahoo dot com dot br
I expected it to be fixed until 5.0.4.
On freeBSD it doesn't work too :(
[2005-03-09 17:29:56] ian at snork dot net
flock() in today's PHP CVS snapshot
(http://snaps.php.net/php5-latest.tar.bz2) behaves slightly
differently, but still doesn't quite work correctly in non-blocking
mode.
Expected result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
$
Releasing /tmp/test1
Got /tmp/test1
Releasing /tmp/test2
Releasing /tmp/test3
Actual result:
--
#31363 [Opn]: Non-blocking flock() broken
ID: 31363
User updated by: ian at snork dot net
Reported By: ian at snork dot net
Status: Open
Bug Type: Filesystem function related
Operating System: Debian woody (i386)
PHP Version: 5CVS-2005-03-09
New Comment:
The cause looks to be two separate bugs; here's a patch to
fix both.
*** php5-200504050030.orig/ext/standard/file.c Sun Mar 27
16:30:05 2005
--- php5-200504050030/ext/standard/file.c Tue Apr 5
15:26:08 2005
***
*** 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (!php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_TRUE;
}
! RETURN_FALSE;
}
/* }}} */
--- 339,351
/* flock_values contains all possible actions if
(operation & 4) we won't block on the lock */
act = flock_values[act - 1] | (operation & 4 ?
LOCK_NB : 0);
! if (php_stream_lock(stream, act)) {
if (operation && errno == EWOULDBLOCK &&
arg3 && PZVAL_IS_REF(arg3)) {
Z_LVAL_P(arg3) = 1;
}
! RETURN_FALSE;
}
! RETURN_TRUE;
}
/* }}} */
*** php5-200504050030.orig/main/streams/plain_wrapper.c
Thu Oct 28 06:35:19 2004
--- php5-200504050030/main/streams/plain_wrapper.c
Tue Apr 5 15:45:51 2005
***
*** 578,584
return 0;
}
! if (!flock(fd, value) || (errno ==
EWOULDBLOCK && value & LOCK_NB)) {
data->lock_flag = value;
return 0;
} else {
--- 578,584
return 0;
}
! if (!flock(fd, value)) {
data->lock_flag = value;
return 0;
} else {
Previous Comments:
[2005-04-05 01:55:32] maurice at gitaar dot net
I had the same problem. It seems that errno is not reset to zero in the
flock implementation. Therefore the last errno will be used. In case no
other errno-modifying call is made before retrying the flock() call,
the call will conclude in an EWOULDBLOCK situation (my conclusion after
a very quick scan of the code).
Looking with truss on Solaris to the process shows that the first fcntl
call (during which I have already locked the file) returns an EAGAIN
error, meaning that the file was already locked. The second fnctl call
(on the now unlocked file) does not return an error. So the call is
successfull. But the call from the php code does set the $wouldblock
parameter to a true value.
For me a workaround for now is something like this (no error checking
on flock and a bit of pseudo-coded, but the workaround is the important
part):
for (;;)
{
flock($fd, LOCK_EX|LOCK_NB, $wouldblock);
if (! $wouldblock) break;
fopen("/this/is/no/real/file", "r");
}
The fopen() call sets errno to the file not found error, which makes
the flock() call act like the first time it is called. This is not
great coding, but it does work for me till a real fix is implemented in
PHP.
[2005-04-01 14:42:19] maka3d at yahoo dot com dot br
I expected it to be fixed until 5.0.4.
On freeBSD it doesn't work too :(
[2005-03-09 17:29:56] ian at snork dot net
flock() in today's PHP CVS snapshot
(http://snaps.php.net/php5-latest.tar.bz2) behaves slightly
differently, but still doesn't quite work correctly in non-blocking
mode.
Expected result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
$
Releasing /tmp/test1
Got /tmp/test1
Releasing /tmp/test2
Releasing /tmp/test3
Actual result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
$
Releasing /tmp/test1
Releasing /tmp/test2
Releasing /tmp/test3
[2005-02-28 21:06:39] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.
#31363 [NoF->Opn]: Non-blocking flock() broken
ID: 31363
User updated by: ian at snork dot net
Reported By: ian at snork dot net
-Status: No Feedback
+Status: Open
Bug Type: Filesystem function related
Operating System: Debian woody (i386)
-PHP Version: 5.0.3
+PHP Version: 5.1.*
New Comment:
flock() in today's PHP CVS snapshot
(http://snaps.php.net/php5-latest.tar.bz2) behaves slightly
differently, but still doesn't quite work correctly in non-blocking
mode.
Expected result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
$
Releasing /tmp/test1
Got /tmp/test1
Releasing /tmp/test2
Releasing /tmp/test3
Actual result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
$
Releasing /tmp/test1
Releasing /tmp/test2
Releasing /tmp/test3
Previous Comments:
[2005-03-08 01:00:24] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
[2005-02-28 21:06:39] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
----------------
[2004-12-31 06:41:56] ian at snork dot net
Description:
This code works in PHP 4.3.0, but does not in PHP 5.0.3.
When invoked, it will try to lock /tmp/test1, /tmp/test2
or /tmp/test3 for exclusive use, whichever is free. If
none are, it will wait a second before cycling through
with another attempt.
When running concurrently, the first invocation correctly
picks up /tmp/test1; the second and subsequent ones just
cycle forever.
For some reason, the non-blocking flock() only sets $block
the first time.
Reproduce code:
---
while (!sleep(1))
foreach (array("/tmp/test1", "/tmp/test2", "/tmp/test3") as $path)
if (flock($handle = fopen($path, "w"), LOCK_EX | LOCK_NB, $block)
and !$block)
{
echo "Got $path\n";
sleep(10);
echo "Releasing $path\n";
exit;
}
Expected result:
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
Releasing /tmp/test1
Got /tmp/test1
$
Actual result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
$ php5 flock_test.php &
$ php5 flock_test.php &
$
--
Edit this bug report at http://bugs.php.net/?id=31363&edit=1
#32144 [Fbk->Opn]: sqlite extension causes crash at PHP startup
ID: 32144
User updated by: ian at snork dot net
Reported By: ian at snork dot net
-Status: Feedback
+Status: Open
Bug Type: SQLite related
Operating System: *
PHP Version: 5.1.*
Assigned To: helly
New Comment:
Replacing mawk with gawk solved the problem.
Many thanks.
Previous Comments:
[2005-03-09 14:31:09] [EMAIL PROTECTED]
You need to install gawk and rebuild. Please verify (for me it helped).
[2005-03-01 11:43:53] ian at snork dot net
Oops -- I meant to say:
Moving phpext_sqlite_ptr and phpext_spl_ptr around in that
list did _not_ prevent a segfault.
Sorry. :)
[2005-03-01 11:37:42] ian at snork dot net
Both SPL and SQLite were built statically into the PHP
binary. I was using an unpatched daily snapshot (from
http://snaps.php.net/php5-latest.tar.bz2). The ./configure
line was:
./configure --without-mime-magic --enable-memory-limit
--disable-debug --with-layout=GNU
--with-pear=/usr/share/php --enable-calendar
--enable-sysvsem --enable-sysvshm --enable-sysvmsg
--enable-track-vars --enable-trans-sid --enable-bcmath
--with-bz2 --enable-ctype --with-db4 --with-iconv
--enable-exif --enable-filepro --enable-ftp --with-gettext
--enable-mbstring --with-pcre-regex=/usr --enable-shmop
--enable-sockets --enable-wddx --disable-xml
--with-expat-dir=/usr --with-xmlrpc --enable-yp
--with-zlib --with-pgsql=/usr --with-kerberos
--with-openssl=/usr --with-exec-dir=/usr/lib/php5/libexec
--prefix=/usr --with-apxs2=/usr/bin/apxs2 --with-regex=php
--with-config-file-path=/etc/php5/apache2 --disable-rpath
--with-curl=/usr --with-dom=/usr --with-dom-xslt=/usr
--with-dom-exslt=/usr --with-zlib-dir=/usr --with-gd=/usr
--enable-gd-native-ttf --with-jpeg-dir=/usr
--with-xpm-dir=/usr/X11R6 --with-png-dir=/usr
--with-freetype-dir=/usr --with-imap=/usr --with-imap-ssl
--with-mcal=/usr --with-mhash=/usr --without-mm
--with-mysql=/usr --with-mysqli=/usr/bin/mysql_config
--with-unixODBC=/usr --enable-xslt=/usr
--with-xslt-sablot=/usr --with-snmp=/usr
--without-sybase-ct --with-ttf=/usr --with-t1lib=/usr
--without-custom-odbc --without-odbc --without-unixODBC
--without-iodbc --with-sqlite=/usr
And here's how they're ordered in the snapshot sources:
zend_module_entry *php_builtin_extensions[] = {
phpext_xmlrpc_ptr,
phpext_xml_ptr,
phpext_wddx_ptr,
phpext_tokenizer_ptr,
phpext_sysvshm_ptr,
phpext_sysvsem_ptr,
phpext_sysvmsg_ptr,
phpext_standard_ptr,
phpext_sqlite_ptr,
phpext_spl_ptr,
phpext_sockets_ptr,
phpext_snmp_ptr,
phpext_simplexml_ptr,
phpext_shmop_ptr,
phpext_session_ptr,
phpext_posix_ptr,
phpext_pgsql_ptr,
phpext_pcre_ptr,
phpext_mysqli_ptr,
phpext_mysql_ptr,
phpext_mhash_ptr,
phpext_mbstring_ptr,
phpext_imap_ptr,
phpext_iconv_ptr,
phpext_gettext_ptr,
phpext_gd_ptr,
phpext_ftp_ptr,
phpext_filepro_ptr,
phpext_exif_ptr,
phpext_dom_ptr,
phpext_dba_ptr,
phpext_curl_ptr,
phpext_ctype_ptr,
phpext_calendar_ptr,
phpext_bz2_ptr,
phpext_bcmath_ptr,
phpext_zlib_ptr,
phpext_openssl_ptr,
phpext_libxml_ptr,
};
Without the patch I submitted, moving phpext_spl_ptr back
or forward in that list did prevent PHP from segfaulting.
After doubled-checking with GDB, it appeared that the SPL
startup function (zm_startup_spl) was not being called at
all.
So, I stuck a manual call to PHP_MINIT(spl) in
basic_functions.c because it seemed the most logical place
for this.
[2005-03-01 10:27:10] [EMAIL PROTECTED]
What is the configure line used? Especially i am interested if spl or
sqlite are build shared. And is this a clean cvs checkout or patched
somewhere? The reason i ask is that for your problem we have a
mechanismn in place already.
Also what is the order of 'phpext_spl_ptr' and
'phpext_sqlite_ptr' in main/internal_functions_*.c's
'php_builtin_extensions' array?
--------------------
[2005-03-01 09:28:29] ian at snork d
#32144 [NEW]: sqlite extension causes crash at PHP startup
From: ian at snork dot net Operating system: Debian sarge (i386) PHP version: 5CVS-2005-03-01 (dev) PHP Bug Type: Reproducible crash Bug description: sqlite extension causes crash at PHP startup Description: A PHP build with --with-spl and --with-sqlite will segfault at startup in all SAPIs because the SPL extension is not initialized at all. The following patch appears to fix the problem: --- php5-200503010530.orig/ext/standard/basic_functions.c 2005-01-18 11:30:05.0 + +++ php5-200503010530/ext/standard/basic_functions.c 2005-03-01 08:03:14.578643275 + @@ -1094,6 +1094,9 @@ PHP_MINIT(syslog)(INIT_FUNC_ARGS_PASSTHRU); #endif PHP_MINIT(array)(INIT_FUNC_ARGS_PASSTHRU); +#ifdef HAVE_SPL + PHP_MINIT(spl)(INIT_FUNC_ARGS_PASSTHRU); +#endif PHP_MINIT(assert)(INIT_FUNC_ARGS_PASSTHRU); PHP_MINIT(url_scanner_ex) (INIT_FUNC_ARGS_PASSTHRU); #ifdef PHP_CAN_SUPPORT_PROC_OPEN Expected result: $ sapi/cli/php /dev/null $ Actual result: -- $ sapi/cli/php /dev/null Segmentation fault $ -- Edit bug report at http://bugs.php.net/?id=32144&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=32144&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=32144&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=32144&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=32144&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=32144&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=32144&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=32144&r=needscript Try newer version: http://bugs.php.net/fix.php?id=32144&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=32144&r=support Expected behavior: http://bugs.php.net/fix.php?id=32144&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=32144&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=32144&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=32144&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=32144&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=32144&r=dst IIS Stability: http://bugs.php.net/fix.php?id=32144&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=32144&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=32144&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=32144&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=32144&r=mysqlcfg
#31363 [NEW]: Non-blocking flock() broken
From: ian at snork dot net
Operating system: Debian woody (i386)
PHP version: 5.0.3
PHP Bug Type: Filesystem function related
Bug description: Non-blocking flock() broken
Description:
This code works in PHP 4.3.0, but does not in PHP 5.0.3.
When invoked, it will try to lock /tmp/test1, /tmp/test2
or /tmp/test3 for exclusive use, whichever is free. If
none are, it will wait a second before cycling through
with another attempt.
When running concurrently, the first invocation correctly
picks up /tmp/test1; the second and subsequent ones just
cycle forever.
For some reason, the non-blocking flock() only sets $block
the first time.
Reproduce code:
---
while (!sleep(1))
foreach (array("/tmp/test1", "/tmp/test2", "/tmp/test3") as $path)
if (flock($handle = fopen($path, "w"), LOCK_EX | LOCK_NB, $block) and
!$block)
{
echo "Got $path\n";
sleep(10);
echo "Releasing $path\n";
exit;
}
Expected result:
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
Got /tmp/test2
$ php5 flock_test.php &
Got /tmp/test3
$ php5 flock_test.php &
Releasing /tmp/test1
Got /tmp/test1
$
Actual result:
--
$ php5 flock_test.php &
Got /tmp/test1
$ php5 flock_test.php &
$ php5 flock_test.php &
$ php5 flock_test.php &
$
--
Edit bug report at http://bugs.php.net/?id=31363&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31363&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31363&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31363&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31363&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31363&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31363&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31363&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31363&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31363&r=support
Expected behavior: http://bugs.php.net/fix.php?id=31363&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31363&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31363&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31363&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31363&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31363&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31363&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31363&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31363&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31363&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31363&r=mysqlcfg
