Bug #63059 [Com]: Failed to build PHP-FPM
Edit report at https://bugs.php.net/bug.php?id=63059&edit=1 ID: 63059 Comment by: rainer dot jung at kippdata dot de Reported by:nam dot nh at nd24 dot net Summary:Failed to build PHP-FPM Status: Closed Type: Bug Package:Compile Failure Operating System: OpenIndiana 151a6 PHP Version:5.4.6 Block user comment: N Private report: N New Comment: Problem still unfixed in PHP 5.4.9 on Solaris 10. Same error as seen by the OP. The patch proposed here wasn't applied, so the problem still exists. Please apply the patch. It is a followup to Bug #62654. There the sapi/fpm/fpm/fpm_sockets.c file was fixed, but the sapi/fpm/fpm/fpm_sockets.h was forgotten. Previous Comments: [2012-10-14 01:43:21] nam dot nh at nd24 dot net Compile successful, then the case is closed [2012-10-14 01:41:58] nam dot nh at nd24 dot net The problem fixed. Thanks. [2012-10-13 17:47:35] mike at maytech dot net See patch attached; should fix the compilation problem. [2012-10-13 15:57:49] nam dot nh at nd24 dot net Found similar to bug #62654, but still get error when "make" [2012-09-11 06:00:16] nam dot nh at nd24 dot net Description: I'm building PHP 5.4.6 on a fresh machine that run OpenIndiana 151a6 OS, gcc version 4.6.3, error happens when do "make" Test script: --- ./configure --prefix=/usr/php --with-gd --with-mcrypt --with-zlib --enable-mbstring --with-mysql=mysqlnd --with-mysqli=mysqlnd --enable-inline-optimization --with-bz2 --enable-sockets --enable-mbregex --with-mhash --enable-zip --with-png-dir=/usr/include --with-jpeg-dir=/usr/include --with-freetype-dir=/usr/include --with-xpm-dir=/usr/include --enable-gd-native-ttf --with-pear=/usr/php/lib/php --disable-ipv6 --enable-fpm Expected result: Successfully Actual result: -- /bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/ -I/usr/src/php-5.4.6/sapi/fpm/ - DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main - I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php- 5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include - I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma - I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php- 5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite - I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /usr/src/php- 5.4.6/sapi/fpm/fpm/fastcgi.c -o sapi/fpm/fpm/fastcgi.lo /bin/sh /usr/src/php-5.4.6/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/src/php-5.4.6/sapi/fpm -Isapi/fpm/ -I/usr/src/php-5.4.6/sapi/fpm/ - DPHP_ATOM_INC -I/usr/src/php-5.4.6/include -I/usr/src/php-5.4.6/main - I/usr/src/php-5.4.6 -I/usr/src/php-5.4.6/ext/date/lib -I/usr/src/php- 5.4.6/ext/ereg/regex -I/usr/include/libxml2 -I/usr/X11R6/include - I/usr/include/freetype2 -I/usr/src/php-5.4.6/ext/mbstring/oniguruma - I/usr/src/php-5.4.6/ext/mbstring/libmbfl -I/usr/src/php- 5.4.6/ext/mbstring/libmbfl/mbfl -I/usr/src/php-5.4.6/ext/sqlite3/libsqlite - I/usr/src/php-5.4.6/TSRM -I/usr/src/php-5.4.6/Zend -D_POSIX_PTHREAD_SEMANTICS -I/usr/include -g -O2 -fvisibility=hidden -c /usr/src/php- 5.4.6/sapi/fpm/fpm/fpm.c -o sapi/fpm/fpm/fpm.lo In file included from /usr/src/php-5.4.6/sapi/fpm/fpm/fpm.c:16:0: /usr/src/php-5.4.6/sapi/fpm/fpm/fpm_sockets.h:28:54: error: expected ';', ',' or ')' before numeric constant make: *** [sapi/fpm/fpm/fpm.lo] Error 1 -- Edit this bug report at https://bugs.php.net/bug.php?id=63059&edit=1
Bug #60901 [Com]: Oracle-11.2 is not detected (too new)
Edit report at https://bugs.php.net/bug.php?id=60901&edit=1 ID: 60901 Comment by: rainer dot jung at kippdata dot de Reported by:lzsiga at freemail dot c3 dot hu Summary:Oracle-11.2 is not detected (too new) Status: Closed Type: Bug Package:OCI8 related Operating System: AIX 6.1 PHP Version:5.3.9 Assigned To:sixd Block user comment: N Private report: N New Comment: Sorry "rading" meant "reading" (typo). 1.4.9 looks fine. Thanks again. Previous Comments: ---- [2012-10-22 19:06:45] rainer dot jung at kippdata dot de I couldn't find 1.4.9 but I agree with the patch by rading and understanding it and also applied the patch and tested it successful on Solaris and Linux. Thanks for your quick fix! [2012-10-22 06:27:43] s...@php.net I re-fixed this and also pushed OCI8 1.4.9 with the fix to PECL. [2012-10-22 05:55:50] s...@php.net Automatic comment on behalf of sixd Revision: http://git.php.net/?p=php-src.git;a=commit;h=dbb72de6c75796803ed6ed103763a12eebc9e78e Log: Re-fixed bug #60901 (Improve "tail" syntax for AIX installation) -------- [2012-10-20 10:51:49] rainer dot jung at kippdata dot de The tail "fix" breaks compilation on Solaris for php version 5.3.18, which worked until version 5.3.17. Not all "tail" implementations support "-n1". On Solaris default "tail" only support "-1". You could switch to using a variable TAIL and auto detect a working tail implementation (understanding "-n"), which on Solaris would be the non standard /usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch. [2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu Okay, thank you for your help. 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 https://bugs.php.net/bug.php?id=60901 -- Edit this bug report at https://bugs.php.net/bug.php?id=60901&edit=1
Bug #60901 [Com]: Oracle-11.2 is not detected (too new)
Edit report at https://bugs.php.net/bug.php?id=60901&edit=1 ID: 60901 Comment by: rainer dot jung at kippdata dot de Reported by:lzsiga at freemail dot c3 dot hu Summary:Oracle-11.2 is not detected (too new) Status: Closed Type: Bug Package:OCI8 related Operating System: AIX 6.1 PHP Version:5.3.9 Assigned To:sixd Block user comment: N Private report: N New Comment: I couldn't find 1.4.9 but I agree with the patch by rading and understanding it and also applied the patch and tested it successful on Solaris and Linux. Thanks for your quick fix! Previous Comments: [2012-10-22 06:27:43] s...@php.net I re-fixed this and also pushed OCI8 1.4.9 with the fix to PECL. [2012-10-22 05:55:50] s...@php.net Automatic comment on behalf of sixd Revision: http://git.php.net/?p=php-src.git;a=commit;h=dbb72de6c75796803ed6ed103763a12eebc9e78e Log: Re-fixed bug #60901 (Improve "tail" syntax for AIX installation) [2012-10-20 10:51:49] rainer dot jung at kippdata dot de The tail "fix" breaks compilation on Solaris for php version 5.3.18, which worked until version 5.3.17. Not all "tail" implementations support "-n1". On Solaris default "tail" only support "-1". You could switch to using a variable TAIL and auto detect a working tail implementation (understanding "-n"), which on Solaris would be the non standard /usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch. [2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu Okay, thank you for your help. [2012-09-14 07:20:07] s...@php.net I merged the "tail" fix. I'm closing this bug out. I understand you'll need to create a symlink like other platforms. 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 https://bugs.php.net/bug.php?id=60901 -- Edit this bug report at https://bugs.php.net/bug.php?id=60901&edit=1
Bug #63327 [Opn]: Crash (Bus Error) in mysqlnd due to wrong alignment
Edit report at https://bugs.php.net/bug.php?id=63327&edit=1
ID: 63327
User updated by:rainer dot jung at kippdata dot de
Reported by:rainer dot jung at kippdata dot de
Summary:Crash (Bus Error) in mysqlnd due to wrong alignment
Status: Open
Type: Bug
-Package:MSSQL related
+Package:MySQL related
Operating System: Solaris Sparc
PHP Version:5.3.18
Block user comment: N
Private report: N
New Comment:
Changed Package from MSSQL to MySQL. Original Package was chosen in error.
Previous Comments:
[2012-10-21 21:26:30] rainer dot jung at kippdata dot de
Description:
All info refers to PHP 5.3.18. The problem goes back to much older 5.3 versions
though. It seems current HEAD contains the same problematic code.
The misalignment can happen as soon as mysqlnd.collect_memory_statistics=On. It
occurs on Solaris Sparc for 32 Bit builds. It is strictly reproducible on my
Solaris 8 system, but not on Solaris 10. This is due to the fact, that a memory
allocation for a size that is only divisibleby 4 but not by 8 can return an
address only divisible by 4 (this happens on my Solaris 8 system) but it can
also return a block of memory starting at an address divisible by 8 (happens by
incident on my Solaris 10 system).
Crash happens in stack:
#0 0x002880f0 in php_mysqlnd_conn_init_pub (conn=0x70dcf4) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2354
No locals.
#1 0x002880a0 in _mysqlnd_init (persistent=0 '\0') at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2380
ret = (MYSQLND *) 0x70dcf4
#2 0xfee742e0 in php_mysql_do_connect (ht=,
return_value=0x70dc40, return_value_ptr=0x0, this_ptr=,
return_value_used=1,
persistent=) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysql/php_mysql.c:965
index_ptr = (zend_rsrc_list_entry *) 0x70e758
new_index_ptr = {ptr = 0x69e8f0, type = 2778356, refcount = 7393472}
user = 0x70db98 "myuser"
passwd = 0x70dc00 "mypass"
host_and_port = 0x70e808 "myserv:3306"
socket = 0x0
tmp =
host = 0x70dc10 "myserv"
user_len = 6
passwd_len = 6
host_len = 11
hashed_details = 0x70dc80 "mysql_myserv:3306_myuser_mypass_131072"
hashed_details_length = 38
port = 3306
client_flags = 131072
mysql =
free_host = 1 '\001'
new_link = 1 '\001'
connect_timeout = 60
Analysis shows, that actually the crash happens immediately before entering
php_mysqlnd_conn_init_pub(), namely in line 2352 of ext/mysqlnd/mysqlnd.c:
2346 /* {{{ mysqlnd_conn::init */
2347 static enum_func_status
2348 MYSQLND_METHOD(mysqlnd_conn, init)(MYSQLND * conn TSRMLS_DC)
2349 {
2350 DBG_ENTER("mysqlnd_conn::init");
2351 mysqlnd_stats_init(&conn->stats, STAT_LAST);
2352 SET_ERROR_AFF_ROWS(conn);
The macro SET_ERROR_AFF_ROWS is defined in ext/mysqlnd/mysqlnd_priv.h as:
#define SET_ERROR_AFF_ROWS(s) (s)->upsert_status.affected_rows = (uint64_t) ~0
So it is important, that "affected_rows" is aligned correctly for 64 Bits. So
lets check the alignment of conn. On my Solaris Sparc system it has size
sizeof(MYSQLND), which is 776 so divisible by 8 and the structure should be
correctly aligned.
But: this is only true if memory statistics for mysqlnd are turned off. If they
are turned On, the allocation of conn is actually done for 776 +sizeof(size_t)
bytes. This is due to the followinglines in ext/mysqlnd/mysqlnd_debug.c:
814 #define REAL_SIZE(s) (collect_memory_statistics? (s) + sizeof(size_t) :
(s))
...
919 /* {{{ _mysqlnd_pecalloc */
920 void * _mysqlnd_pecalloc(unsigned int nmemb, size_t size, zend_bool
persistent MYSQLND_MEM_D)
921 {
...
932 ret = pecalloc(nmemb, REAL_SIZE(size), persistent);
So here instead of allocating 776 bytes, we allocate 776+sizeof(size_t) = 776+4
= 780 bytes which is no longer divisible by 8! So memory allocation not
necessarily allocates at 8 bytes alignment.
To fix it I expect you need to replace sizeof(size_t) in the following lines by
a size that does not reduce alignment for any allocation done in
mysqlnd_debug.c. Using sizeof(uint64_t) might suffice for the time being.
814 #define REAL_SIZE(s) (collect_memory_statistics? (s) + sizeof(size_t) :
(s))
815 #define REAL_PTR(p) (collect_memory_statistics && (p)? (((char *)(p)) -
sizeof(size_t)) : (p))
816 #define FAKE_PTR(p) (collect_memory_statistics && (p)? (((char *)(p)) +
sizeof(size_t)) : (p))
In HEAD you can find the same problem in file mysqlnd_alloc.c.
Not
[PHP-BUG] Bug #63327 [NEW]: Crash (Bus Error) in mysqlnd due to wrong alignment
From: rainer dot jung at kippdata dot de
Operating system: Solaris Sparc
PHP version: 5.3.18
Package: MSSQL related
Bug Type: Bug
Bug description:Crash (Bus Error) in mysqlnd due to wrong alignment
Description:
All info refers to PHP 5.3.18. The problem goes back to much older 5.3
versions though. It seems current HEAD contains the same problematic code.
The misalignment can happen as soon as
mysqlnd.collect_memory_statistics=On. It occurs on Solaris Sparc for 32 Bit
builds. It is strictly reproducible on my Solaris 8 system, but not on
Solaris 10. This is due to the fact, that a memory allocation for a size
that is only divisibleby 4 but not by 8 can return an address only
divisible by 4 (this happens on my Solaris 8 system) but it can also return
a block of memory starting at an address divisible by 8 (happens by
incident on my Solaris 10 system).
Crash happens in stack:
#0 0x002880f0 in php_mysqlnd_conn_init_pub (conn=0x70dcf4) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2354
No locals.
#1 0x002880a0 in _mysqlnd_init (persistent=0 '\0') at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysqlnd/mysqlnd.c:2380
ret = (MYSQLND *) 0x70dcf4
#2 0xfee742e0 in php_mysql_do_connect (ht=,
return_value=0x70dc40, return_value_ptr=0x0, this_ptr=, return_value_used=1,
persistent=) at
/shared/build/autobuild/workdirs/20121021_163211/bld/php53/ext/mysql/php_mysql.c:965
index_ptr = (zend_rsrc_list_entry *) 0x70e758
new_index_ptr = {ptr = 0x69e8f0, type = 2778356, refcount =
7393472}
user = 0x70db98 "myuser"
passwd = 0x70dc00 "mypass"
host_and_port = 0x70e808 "myserv:3306"
socket = 0x0
tmp =
host = 0x70dc10 "myserv"
user_len = 6
passwd_len = 6
host_len = 11
hashed_details = 0x70dc80 "mysql_myserv:3306_myuser_mypass_131072"
hashed_details_length = 38
port = 3306
client_flags = 131072
mysql =
free_host = 1 '\001'
new_link = 1 '\001'
connect_timeout = 60
Analysis shows, that actually the crash happens immediately before entering
php_mysqlnd_conn_init_pub(), namely in line 2352 of ext/mysqlnd/mysqlnd.c:
2346 /* {{{ mysqlnd_conn::init */
2347 static enum_func_status
2348 MYSQLND_METHOD(mysqlnd_conn, init)(MYSQLND * conn TSRMLS_DC)
2349 {
2350 DBG_ENTER("mysqlnd_conn::init");
2351 mysqlnd_stats_init(&conn->stats, STAT_LAST);
2352 SET_ERROR_AFF_ROWS(conn);
The macro SET_ERROR_AFF_ROWS is defined in ext/mysqlnd/mysqlnd_priv.h as:
#define SET_ERROR_AFF_ROWS(s) (s)->upsert_status.affected_rows = (uint64_t)
~0
So it is important, that "affected_rows" is aligned correctly for 64 Bits.
So lets check the alignment of conn. On my Solaris Sparc system it has size
sizeof(MYSQLND), which is 776 so divisible by 8 and the structure should be
correctly aligned.
But: this is only true if memory statistics for mysqlnd are turned off. If
they are turned On, the allocation of conn is actually done for 776
+sizeof(size_t) bytes. This is due to the followinglines in
ext/mysqlnd/mysqlnd_debug.c:
814 #define REAL_SIZE(s) (collect_memory_statistics? (s) +
sizeof(size_t) : (s))
...
919 /* {{{ _mysqlnd_pecalloc */
920 void * _mysqlnd_pecalloc(unsigned int nmemb, size_t size, zend_bool
persistent MYSQLND_MEM_D)
921 {
...
932 ret = pecalloc(nmemb, REAL_SIZE(size),
persistent);
So here instead of allocating 776 bytes, we allocate 776+sizeof(size_t) =
776+4 = 780 bytes which is no longer divisible by 8! So memory allocation
not necessarily allocates at 8 bytes alignment.
To fix it I expect you need to replace sizeof(size_t) in the following
lines by a size that does not reduce alignment for any allocation done in
mysqlnd_debug.c. Using sizeof(uint64_t) might suffice for the time being.
814 #define REAL_SIZE(s) (collect_memory_statistics? (s) +
sizeof(size_t) : (s))
815 #define REAL_PTR(p) (collect_memory_statistics && (p)? (((char
*)(p)) - sizeof(size_t)) : (p))
816 #define FAKE_PTR(p) (collect_memory_statistics && (p)? (((char
*)(p)) + sizeof(size_t)) : (p))
In HEAD you can find the same problem in file mysqlnd_alloc.c.
Note: this problem is *not* the same as the alignment problem in mysqlnd I
reported 2.5 years ago in https://bugs.php.net/bug.php?id=51583.
Regards,
Rainer
Test script:
---
MySQL Test
';
$connection = mysql_connect("$db_server:$db_port", $db_username,
$db_password, $db_name);
if (! $connection) {
echo "ERROR - Unable to connect to database server
'$db_server:$db_port': ". mysql_error() . '';
} else {
mysql_close($connection);
}
?>
Actual result:
-
Bug #60901 [Com]: Oracle-11.2 is not detected (too new)
Edit report at https://bugs.php.net/bug.php?id=60901&edit=1 ID: 60901 Comment by: rainer dot jung at kippdata dot de Reported by:lzsiga at freemail dot c3 dot hu Summary:Oracle-11.2 is not detected (too new) Status: Closed Type: Bug Package:OCI8 related Operating System: AIX 6.1 PHP Version:5.3.9 Assigned To:sixd Block user comment: N Private report: N New Comment: The tail "fix" breaks compilation on Solaris for php version 5.3.18, which worked until version 5.3.17. Not all "tail" implementations support "-n1". On Solaris default "tail" only support "-1". You could switch to using a variable TAIL and auto detect a working tail implementation (understanding "-n"), which on Solaris would be the non standard /usr/xpg4/bin/tail. Users could overwrite with a new --with-tail switch. Previous Comments: [2012-09-14 08:00:23] lzsiga at freemail dot c3 dot hu Okay, thank you for your help. [2012-09-14 07:20:07] s...@php.net I merged the "tail" fix. I'm closing this bug out. I understand you'll need to create a symlink like other platforms. [2012-09-14 07:18:13] s...@php.net Automatic comment on behalf of sixd Revision: http://git.php.net/?p=php-src.git;a=commit;h=bbf5978e2641d924c2d4d1c47210756943a28f7b Log: Fixed bug #60901 (Improve "tail" syntax for AIX installation) [2012-09-13 08:16:20] lzsiga at freemail dot c3 dot hu A new aspect of this problem: an over-zealous version of 'tail' wouldn't accept syntax 'tail -1' only 'tail -n1' (in this line in configure: OCI8_LCS=`ls $OCI8_LCS_BASE.*.1 2> /dev/null | tail -1` # Oracle 10g, 11g etc ) [2012-02-23 21:42:00] s...@php.net What created libclntsh.so.11.2? The instantclient-basic-aix.ppc64- 11.2.0.3.0.zip and instantclient-basic-aix.ppc32-11.2.0.3.0.zip files only contain libclntsh.so I don't consider creating a libcntsh.so.11.1 symlink such a hack, since creating the reverse symlink is required on other platforms. See http://docs.oracle.com/cd/E11882_01/appdev.112/e10646/oci01int.htm#LNOCI16174 However I can improve the installation experience on AIX once I understand what the installed environment commonly looks like. 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 https://bugs.php.net/bug.php?id=60901 -- Edit this bug report at https://bugs.php.net/bug.php?id=60901&edit=1
Bug #50345 [Com]: nanosleep not detected properly on some solaris versions
Edit report at http://bugs.php.net/bug.php?id=50345&edit=1 ID: 50345 Comment by: rainer dot jung at kippdata dot de Reported by: sle at ocf dot berkeley dot edu Summary: nanosleep not detected properly on some solaris versions Status: Closed Type: Bug Package: Compile Failure Operating System: Solaris 10 PHP Version: 5.3.1 Assigned To: jani New Comment: Sorry: I meant r297961. BTW: this is a regression, it was already fixed successful in 5.3.2. Previous Comments: [2010-07-23 13:51:25] rainer dot jung at kippdata dot de Unfortunately the issue needs to be reopened. The change in revision 297960 reintroduced this problem, at least on Solaris 8, but likely also on more modern Solaris. Before the change library rt was added to EXTRA_LIBS, after the change the symbol __nanosleep is found and the library no longer added. During linking we then get (as expected): Undefined first referenced symbol in file nanosleep ext/standard/.libs/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Observed for version 5.3.3. Reverting the pseudo-optimization in r297960 fixes the issue. Thanks for considering this, Rainer [2009-12-02 18:01:36] j...@php.net Closing then. Thanks for testing. [2009-12-02 16:23:07] sle at ocf dot berkeley dot edu The patch appears to have fixed the bug. I am now able to successfully compile PHP 5.3 without modifying the generated Makefile. I'm running the test suites right now, but everything appears to be working. Thanks for your help! [2009-12-02 08:55:57] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ But in about 35 minutes earliest so that the fix gets in it. :) [2009-12-02 08:54:51] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=291584 Log: - Fixed bug #50345 (nanosleep not detected properly on some solaris versions) 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/bug.php?id=50345 -- Edit this bug report at http://bugs.php.net/bug.php?id=50345&edit=1
Bug #50345 [Com]: nanosleep not detected properly on some solaris versions
Edit report at http://bugs.php.net/bug.php?id=50345&edit=1 ID: 50345 Comment by: rainer dot jung at kippdata dot de Reported by: sle at ocf dot berkeley dot edu Summary: nanosleep not detected properly on some solaris versions Status: Closed Type: Bug Package: Compile Failure Operating System: Solaris 10 PHP Version: 5.3.1 Assigned To: jani New Comment: Unfortunately the issue needs to be reopened. The change in revision 297960 reintroduced this problem, at least on Solaris 8, but likely also on more modern Solaris. Before the change library rt was added to EXTRA_LIBS, after the change the symbol __nanosleep is found and the library no longer added. During linking we then get (as expected): Undefined first referenced symbol in file nanosleep ext/standard/.libs/basic_functions.o ld: fatal: Symbol referencing errors. No output written to sapi/cli/php collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 Observed for version 5.3.3. Reverting the pseudo-optimization in r297960 fixes the issue. Thanks for considering this, Rainer Previous Comments: [2009-12-02 18:01:36] j...@php.net Closing then. Thanks for testing. [2009-12-02 16:23:07] sle at ocf dot berkeley dot edu The patch appears to have fixed the bug. I am now able to successfully compile PHP 5.3 without modifying the generated Makefile. I'm running the test suites right now, but everything appears to be working. Thanks for your help! [2009-12-02 08:55:57] j...@php.net Please try using this snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ But in about 35 minutes earliest so that the fix gets in it. :) [2009-12-02 08:54:51] s...@php.net Automatic comment from SVN on behalf of jani Revision: http://svn.php.net/viewvc/?view=revision&revision=291584 Log: - Fixed bug #50345 (nanosleep not detected properly on some solaris versions) [2009-12-01 23:52:35] sle at ocf dot berkeley dot edu -lrt is only mentioned in config.log when searching for -lcurl. I suspect this is due to curl-config recommending -lrt for its linker flags. With regards to nanosleep, ### snip from config.log ### configure:15225: checking for nanosleep configure:15253: /usr/sfw/bin/gcc -o conftest -I/opt/ocf/include -I/usr/sfw/incl ude -I/opt/ocf/include -I/usr/sfw/include -D_POSIX_PTHREAD_SEMANTICS -L/opt/ocf/ lib -R/opt/ocf/lib -L/usr/sfw/lib -R/usr/sfw/lib -R/usr/ucblib -L/usr/ucblib con ftest.c -lm -lnsl -lsocket 1>&5 Undefined first referenced symbol in file nanosleep /var/tmp//ccYTdffo.o ld: fatal: Symbol referencing errors. No output written to conftest ### end snip ### since the test failed, it shouldn't have been defined. However, I do see the following later: ### snip from config.log ### configure:15271: checking for __nanosleep configure:15299: /usr/sfw/bin/gcc -o conftest -I/opt/ocf/include -I/usr/sfw/incl ude -I/opt/ocf/include -I/usr/sfw/include -D_POSIX_PTHREAD_SEMANTICS -L/opt/ocf/ lib -R/opt/ocf/lib -L/usr/sfw/lib -R/usr/sfw/lib -R/usr/ucblib -L/usr/ucblib con ftest.c -lm -lnsl -lsocket 1>&5 ### end snip ### that test seems to be successful: ### snip from configure output ### checking for nanosleep... no checking for __nanosleep... yes ### end snip ### 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/bug.php?id=50345 -- Edit this bug report at http://bugs.php.net/bug.php?id=50345&edit=1
Bug #51583 [Csd]: Bus error due to wrong alignment in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=51583&edit=1
ID: 51583
User updated by: rainer dot jung at kippdata dot de
Reported by: rainer dot jung at kippdata dot de
Summary: Bus error due to wrong alignment in mysqlnd
Status: Closed
Type: Bug
Package: MySQL related
Operating System: Solaris Sparc
PHP Version: 5.3.2
Assigned To: mysql
New Comment:
Sorry to bother you again:
In view of the forthcoming 5.3.3 release I checked today's source code.
I can't find any signs of the patch, neither in trunk nor for 5.3.
I then went through the full svn log of ext/mysqlnd for trunk and 5.3
and found no log message which seems to be related to this fix.
Furthermore the full svn log of trunk and 5.3 do not mention the bug
number anywhere.
So I doubt whether the patch realy has been applied. Could you please
provide the revision number of a subversion commit, where the problem
has been fixed?
Thanks,
Rainer
Previous Comments:
[2010-07-06 13:02:14] and...@php.net
Patch is in branch and trunk, will appear in 5.3.3.
Thanks!
[2010-04-19 17:03:18] and...@php.net
I will take care of this. This week my Linux/Sparc box will be running
again.
[2010-04-17 22:55:25] rainer dot jung at kippdata dot de
I checked the snapshot. Exactly the same problem. Please have a look at
my analysis and patch proposal. Thanks!
[2010-04-17 18:29:20] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-17 17:44:54] rainer dot jung at kippdata dot de
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 "", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 "", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = "\000\000\000"
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63 ""
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = "\000\000\000\000\001"
net = (MYSQLND_NET *) 0x669370
written =
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=, arg_len=, ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret =
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret =
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT,
STAT_CLOSE_IMPLICIT, STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63 ""
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn->net->m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print &buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that "buffer" gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the a
Bug #51583 [Fbk->Opn]: Bus error due to wrong alignment in mysqlnd
Edit report at http://bugs.php.net/bug.php?id=51583&edit=1
ID: 51583
User updated by: rainer dot jung at kippdata dot de
Reported by: rainer dot jung at kippdata dot de
Summary: Bus error due to wrong alignment in mysqlnd
-Status: Feedback
+Status: Open
Type: Bug
Package: MySQL related
Operating System: Solaris Sparc
PHP Version: 5.3.2
Assigned To: mysql
New Comment:
I checked the snapshot. Exactly the same problem. Please have a look at
my analysis and patch proposal. Thanks!
Previous Comments:
[2010-04-17 18:29:20] fel...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2010-04-17 17:44:54] rainer dot jung at kippdata dot de
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 "", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928,
buf=0xffbeee63 "", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = "\000\000\000"
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63 ""
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = "\000\000\000\000\001"
net = (MYSQLND_NET *) 0x669370
written =
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=, arg_len=, ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret =
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret =
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT,
STAT_CLOSE_IMPLICIT, STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63 ""
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8,
conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn->net->m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print &buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that "buffer" gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the above example it was allocated in line 680 of
mysqlnd_wireprotocol.c,
without any alignment enforcement: "char buffer[MYSQLND_HEADER_SIZE +
1];"
- thus casting buffer to an (unsigned int *) crashes
Since both macros STORE_HEADER_SIZE and RESTORE_HEADER_SIZE seem to be
used in places, where there can be made no assumption about the
alignment of the buffer, the attached patch proposes to copy the header
bytes as four individual byte operations. Platform specific
optimizations might be applied, but at least the patch seems to be a
robust solution. The patch was done against trunk, same patch applies
with offset to 5_3 branch.
Test script:
---
MySQL Test
';
$connection = mysql_connect("$db_server:$db_port", $db_username,
$db_password, $db_name);
if (! $connection) {
echo "ERROR - Unable to connect to database server
'$db_server:$db_port': ". mysql_error() . '';
return FALSE;
}
echo 'Host Info: ' . mysql_get_host_info() . '';
echo &#x
[PHP-BUG] Bug #51583 [NEW]: Bus error due to wrong alignment in mysqlnd
From:
Operating system: Solaris Sparc
PHP version: 5.3.2
Package: MySQL related
Bug Type: Bug
Bug description:Bus error due to wrong alignment in mysqlnd
Description:
Using any of pdo-mysql, mysqli or mysql against mysqlnd results in a bus
error on Solaris Sparc. This is due to a wrong alignment assumption that
produces crashes because Sparc is strict about alignment.
The resulting core inspected via GDB shows:
Core was generated by `bin/php -c lib/php.ini mysql.php'.
Program terminated with signal 10, Bus error.
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928, buf=0xffbeee63
"", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
281 STORE_HEADER_SIZE(safe_storage, p);
(gdb) bt full
#0 0x0027d7f4 in php_mysqlnd_net_send_pub (conn=0x669928, buf=0xffbeee63
"", count=1)
at /some/path/php53/ext/mysqlnd/mysqlnd_net.c:281
safe_buf = "\000\000\000"
net = (MYSQLND_NET *) 0x669370
old_chunk_size = 8192
ret = 0
packets_sent = 1
left = 1
p = (zend_uchar *) 0xffbeee63 ""
compress_buf = (zend_uchar *) 0x0
to_be_sent = 1
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8, conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
buffer = "\000\000\000\000\001"
net = (MYSQLND_NET *) 0x669370
written =
#2 0x00272154 in php_mysqlnd_conn_simple_command_pub (conn=0x669928,
command=COM_QUIT, arg=, arg_len=,
ok_packet=PROT_LAST,
silent=1 '\001', ignore_upsert_status=1 '\001') at
/some/path/php53/ext/mysqlnd/mysqlnd.c:380
_p_s = (MYSQLND_STATS *) 0x7efa10
ret =
cmd_packet = (MYSQLND_PACKET_COMMAND *) 0x6692b8
#3 0x0026f920 in mysqlnd_send_close (conn=0x669928) at
/some/path/php53/ext/mysqlnd/mysqlnd.c:1393
ret =
#4 0x00270560 in php_mysqlnd_conn_close_pub (conn=0x669928,
close_type=)
at /some/path/php53/ext/mysqlnd/mysqlnd.c:1461
_p_s = (MYSQLND_STATS *) 0x7dafb8
stat = STAT_CLOSE_EXPLICIT
close_type_to_stat_map = {STAT_CLOSE_EXPLICIT, STAT_CLOSE_IMPLICIT,
STAT_CLOSE_DISCONNECT}
#5 0xfee47a70 in _close_mysql_link (rsrc=0x672150) at
/some/path/php53/ext/mysql/php_mysql.c:355
link = (php_mysql_conn *) 0x669358
handler = (void (*)(int)) 0x1
...
(gdb) print p
$1 = (zend_uchar *) 0xffbeee63 ""
(gdb) up
#1 0x0027552c in php_mysqlnd_cmd_write (_packet=0x6692b8, conn=0x669928)
at /some/path/php53/ext/mysqlnd/mysqlnd_wireprotocol.c:683
683 written = conn->net->m.send(conn, buffer, 1
TSRMLS_CC);
(gdb) print &buffer
$2 = (char (*)[5]) 0xffbeee63
Further Analysis shows:
- STORE_HEADER_SIZE() is a macro defined in the same file as:
int4store((safe_storage), (*(uint32_t *)(buffer)))
Note that "buffer" gets cast via (uint32_t *)
- buffer is not aligned on a 4 byte boundary, in fact it is an odd
address.
In the above example it was allocated in line 680 of
mysqlnd_wireprotocol.c,
without any alignment enforcement: "char buffer[MYSQLND_HEADER_SIZE +
1];"
- thus casting buffer to an (unsigned int *) crashes
Since both macros STORE_HEADER_SIZE and RESTORE_HEADER_SIZE seem to be used
in places, where there can be made no assumption about the alignment of the
buffer, the attached patch proposes to copy the header bytes as four
individual byte operations. Platform specific optimizations might be
applied, but at least the patch seems to be a robust solution. The patch
was done against trunk, same patch applies with offset to 5_3 branch.
Test script:
---
MySQL Test
';
$connection = mysql_connect("$db_server:$db_port", $db_username,
$db_password, $db_name);
if (! $connection) {
echo "ERROR - Unable to connect to database server
'$db_server:$db_port': ". mysql_error() . '';
return FALSE;
}
echo 'Host Info: ' . mysql_get_host_info() . '';
echo 'Server Info: ' . mysql_get_server_info() . '';
echo 'Protocol Info: ' . mysql_get_proto_info() . '';
echo 'Client Info: ' . mysql_get_client_info() . '';
mysql_close($connection);
?>
Expected result:
MySQL Test
Connecting ...Host Info: sorbus-07 via TCP/IPServer Info:
5.0.27-standardProtocol Info: 10Client Info: mysqlnd 5.0.7-dev -
091210 - $Revision: 294543 $
Actual result:
--
MySQL Test
Connecting ...Host Info: sorbus-07 via TCP/IPServer Info:
5.0.27-standardProtocol Info: 10Client Info: mysqlnd 5.0.7-dev -
091210 - $Revision: 294543 $Bus Error (core dumped)
Note the trailing "Bus Error ..".
The result was produced by running PHP via CLI.
--
Edit bug report at http://bugs.php.net/bug.php?id=51583&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51583&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51583&r=trysnapshot53
Try a snapshot (PHP
#47831 [NEW]: Compile warning for strnlen() in main/spprintf.c (missing #define _GNU_SOURCE)
From: rainer dot jung at kippdata dot de Operating system: Linux PHP version: 5.2.9 PHP Bug Type: Compile Warning Bug description: Compile warning for strnlen() in main/spprintf.c (missing #define _GNU_SOURCE) Description: PHP 5.2.9 does auto detection for strnlen(). On Linux the detection results in strnlen() availability. The function is only available, when _GNU_SOURCE is defined though. File main/spprintf.c uses it without _GNU_SOURCE in PHP 5.2.9. This is due to an incomplete backport from MAIN and 5.3. See http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.25.2.2.2.10.2.4&r2=1.25.2.2.2.10.2.5 and http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.53&r2=1.54&; and compare with http://cvs.php.net/viewvc.cgi/php-src/main/spprintf.c?r1=1.25.2.2.2.14&r2=1.25.2.2.2.15 Patch: --- main/spprintf.c 2009-02-04 16:03:12.0 +0100 +++ main/spprintf.c 2009-03-29 21:58:10.0 +0200 @@ -76,6 +76,7 @@ * SIO stdio-replacement strx_* functions by Panos Tsirigotis * for xinetd. */ +#define _GNU_SOURCE #include "php.h" #include -- Edit bug report at http://bugs.php.net/?id=47831&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47831&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47831&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47831&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47831&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47831&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47831&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47831&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47831&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47831&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47831&r=support Expected behavior: http://bugs.php.net/fix.php?id=47831&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47831&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47831&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47831&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47831&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47831&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47831&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47831&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47831&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47831&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47831&r=mysqlcfg
