Bug #51266 [Com]: stat failed on cifs-mounted files

2011-11-30 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=51266&edit=1

 ID: 51266
 Comment by: brandonkirsch at gmail dot com
 Reported by:dctucker at hotmail dot com
 Summary:stat failed on cifs-mounted files
 Status: Feedback
 Type:   Bug
 Package:Filesystem function related
 Operating System:   Arch Linux (current)
 PHP Version:5.3.2
 Block user comment: N
 Private report: N

 New Comment:

We recently upgraded our underlying Linux OS and ran into this same issue.  For 
other Googlers who come across this bug report:  Use the "noserverino" mount 
option as specified by others.

If you want to know more about this issue, see: 
http://linux.die.net/man/8/mount.cifs

The important thing to know is that CIFS servers will frequently return inode 
integer values that are greater than 31^2. If you read the PHP documentation 
for 
these filesystem functions, you will find a disclaimer that these large 
unsigned 
integer values will break in PHP.

Disable the possibility of really big inode numbers from your CIFS mounts by 
using the "noserverino" mount option.


Previous Comments:

[2010-07-30 15:20:05] beststom14 at hotmail dot com

Same issue. Windows Seven 32 bit. When programming a file manager i found that 
some dirs were being listed as files. For some reason when i create a new dir 
it gets listed correctly but when i COPY it from somewhere it is listed as a 
file.


[2010-06-04 08:32:44] m...@php.net

Cannot reproduce, still works fine here.

When you edit your report, please re-open it, too.


[2010-06-03 20:37:31] dctucker at hotmail dot com

The mount command lacks noserverino:

$ tail -n 1 /etc/fstab
//theword/d  /mnt/theword  cifs
nocase,file_mode=0664,dir_mode=0775,username=Administrator%,uid=nobody 0 0


[2010-05-21 11:23:44] m...@php.net

How does the mount command look like, so that it fails?


[2010-05-20 21:54:15] dctucker at hotmail dot com

Mike,

Using the 'noserverino' workaround does mitigate the problem, but it does not 
address the underlying issue.




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=51266


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=51266&edit=1

Bug #54007 [Com]: odbc seg faults with null data returned from DB2

2013-04-08 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=54007&edit=1

 ID: 54007
 Comment by: brandonkirsch at gmail dot com
 Reported by:ken at focusschoolsoftware dot com
 Summary:odbc seg faults with null data returned from DB2
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   Linux
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Hi friends,

I have a fix for this problem, which is caused by some rich history in the 
written standard for ODBC.  IBM's "64-bit" ODBC drivers are written against an 
older specification, and they are affected by changes in the size of SQLLEN / 
SQLULEN types as the specification has evolved.

The "correct" solution for this problem is for IBM to release iSeriesAccess 
ODBC drivers that fit the modern specification for 64-bit ODBC.

A workaround that we successfully used in production for several years includes 
casting certain 64-bit ODBC values down to 32-bits when comparing for 
SQL_NULL_DATA. It essentially changes PHP to conform to an outdated ODBC spec 
that IBM requires. It doesn't break other "real" 64-bit ODBC drivers as long as 
you aren't pulling back individual values > 4GB.

I'll re-iterate that PHP is using the correct specification for 64-bit ODBC, so 
this is *NOT* a bug. But if you need compatibility with IBM in a 64-bit 
environment, you can have / study / re-use the workaround I developed and 
posted at http://perceptionilluminates.com/php/php_odbc.c


Previous Comments:

[2012-10-19 12:16:09] tuomas dot angervuori at gmail dot com

Seems that this bug is somehow 64bit related. I get segmentation fault on my 
64bit ubuntu 12.04 (php-5.3.10 & IBM i Access 7.1) but not with 32bit Debian 
(php-5.3.3 & IBM i Access 7.1).

I can do more tests & provide more detailed information if needed.


[2011-11-10 09:38:10] giuseppe at blandino dot it

I've the same problem.
I'm trying to migrate my web applications from an old Ubuntu server 64bit with 
PHP 5.2.4 and DB2 9.1.0 to a new Ubuntu 10.4 LTS 64 bit server with PHP Version 
5.3.2-1ubuntu4.10, Apache/2.2.14 and DB2 ver. 9.7.4.
This is a sample of code:

  $sql = "SELECT field FROM table WHERE ...";
  $result = odbc_exec($id_connect, $sql);
  if (odbc_fetch_row($result)) {
  $field = (int) odbc_result($result,"field");
   // seg fault when field is null   
  }

But if I try this:

  $sql = "SELECT field FROM table WHERE ...";
  $result = odbc_exec($id_connect, $sql);
  odbc_result_all($result);

it don't crash but give:

  FIELD
  vÖN ’\UJõÕseõº\ŠŒ+ŽT9

It seems that when field is null the ODBC driver return the pointer of 
somewhere in the memory...


[2011-07-22 15:19:53] hborrel at gmail dot com

We have the same problem.

As a work around we've had to add this to any feild that may return a NULL.

COALESCE(CHAR(DELIVERYDATE), '')


[2011-02-13 19:07:17] ken at focusschoolsoftware dot com

FYI:
php_odbc.c:2158 -> RETURN_STRINGL(result->values[field_ind].value, result-
>values[field_ind].vallen, 1);


[2011-02-13 19:05:10] ken at focusschoolsoftware dot com

Backtrace:
#0  0x76879ea1 in memcpy () from /lib/libc.so.6
#1  0x006af648 in _estrndup (s=0x757cd4b8 "", 
length=) at /usr/include/bits/string3.h:52
#2  0x75edadcb in zif_odbc_result (ht=, 
return_value=0x757d6940, return_value_ptr=, 
this_ptr=, return_value_used=, 
tsrm_ls=0xc91090)
at /home/focus/Development/php-5.3.5/ext/odbc/php_odbc.c:2158
#3  0x0072730d in zend_do_fcall_common_helper_SPEC (
execute_data=0x77ed39a0, tsrm_ls=0xc91090)
at /home/focus/Development/php-5.3.5/Zend/zend_vm_execute.h:316
#4  0x006f927b in execute (op_array=0xeeb010, tsrm_ls=0xc91090)
at /home/focus/Development/php-5.3.5/Zend/zend_vm_execute.h:107
#5  0x006cec48 in zend_execute_scripts (type=, 
tsrm_ls=0xc91090, retval=, file_count=3)
at /home/focus/Development/php-5.3.5/Zend/zend.c:1194
#6  0x00670e2d in php_execute_script (
primary_file=, tsrm_ls=)
at /home/focus/Development/php-5.3.5/main/main.c:2265
#7  0x00767abe in main (argc=, 
argv=)
at /home/focus/Development/php-5.3.5/sapi/cli/php_cli.c:1193




The remainder of the comments for this report are too long. To view
the rest of the com

[PHP-BUG] Bug #64611 [NEW]: Segfault using ODBC with SQL Server "Native Client"

2013-04-08 Thread brandonkirsch at gmail dot com 
From: brandonkirsch at gmail dot com
Operating system: Linux  - OpenSuse 12.2 64-bit
PHP version:  5.5.0beta1
Package:  ODBC related
Bug Type: Bug
Bug description:Segfault using ODBC with SQL Server "Native Client"

Description:

A segfault has existed in PHP since at least 5.2.17 when using ODBC with
SQL Server Native Client driver.

Selecting NULL values in a computed expression causes the segfault.

I created a patch for this over a year ago and submitted the pull request
here: https://github.com/php/php-src/pull/193

The pull request has not been accepted, so the segfault still exists even
in 5.5.0beta2.



Test script:
---
https://bugs.php.net/bug.php?id=64611&edit=1
-- 
Try a snapshot (PHP 5.4):   
https://bugs.php.net/fix.php?id=64611&r=trysnapshot54
Try a snapshot (PHP 5.3):   
https://bugs.php.net/fix.php?id=64611&r=trysnapshot53
Try a snapshot (trunk): 
https://bugs.php.net/fix.php?id=64611&r=trysnapshottrunk
Fixed in SVN:   https://bugs.php.net/fix.php?id=64611&r=fixed
Fixed in release:   https://bugs.php.net/fix.php?id=64611&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64611&r=needtrace
Need Reproduce Script:  https://bugs.php.net/fix.php?id=64611&r=needscript
Try newer version:  https://bugs.php.net/fix.php?id=64611&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64611&r=support
Expected behavior:  https://bugs.php.net/fix.php?id=64611&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64611&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64611&r=submittedtwice
register_globals:   https://bugs.php.net/fix.php?id=64611&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64611&r=php4
Daylight Savings:   https://bugs.php.net/fix.php?id=64611&r=dst
IIS Stability:  https://bugs.php.net/fix.php?id=64611&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64611&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64611&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64611&r=nozend
MySQL Configuration Error:  https://bugs.php.net/fix.php?id=64611&r=mysqlcfg

Bug #61387 [Com]: NULL valued anonymous column causes segfault in odbc_fetch_array

2013-04-15 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61387&edit=1

 ID: 61387
 Comment by: brandonkirsch at gmail dot com
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
 Status: Assigned
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Assigned To:ssb
 Block user comment: N
 Private report: N

 New Comment:

Here's a fix for this issue: https://github.com/php/php-src/pull/193

Please accept it! Would be nice to have a fix before the next 5.5 beta.


Previous Comments:

[2013-04-09 02:57:22] larue...@php.net

ssb, are you still active for odbc bugs fix?


[2012-09-12 23:51:50] brandonkirsch at gmail dot com

This problem is isolated to the SQL Server Native Client ODBC Driver. Most 
other 
ODBC drivers will automatically provide some type of aliased column name for 
arbitrary values that you select.

When using a SELECT 'VALUE' statement with SQL Server ODBC, the 
php_odbc_fetch_hash() function returns the column as 'VALUE' => 'VALUE' -- that 
is, the value you select is also the key in the array.

The problem occurs at the end of the php_odbc_fetch_hash() function in 
php_odbc.c (for me, on 5.2.17 it begins on line 1510) and it looks like this:

if (!*(result->values[i].name)) { // GDB says this evaluates to 1
  zend_hash_update(Z_ARRVAL_P(return_value), Z_STRVAL_P(tmp),
Z_STRLEN_P(tmp)+1, &tmp, sizeof(zval *), NULL); // SEGFAULT

This usage of zend_hash_update() causes a segfault in PHP 5.2.17 and PHP 
5.3.16.  
I guess that result->values[i].name looks legit and/or usable when it is not.

I updated the if statement to read:

if (!*(result->values[i].name) && Z_TYPE_P(tmp) != IS_NULL) { // Evaluates 
false 
for SQL NULLs that sets ZVAL_NULL(tmp)

This skips the incorrect usage of zend_hash_update with Z_STR* functions and 
proceeds to the "else" condition that handles it correctly.

For us, this solution works perfectly and the end-result is array("" => NULL) 
instead of a segfault.  Other unaliased NULL values from other databases 
continue to work the same way as before (iSeries ODBC drivers return 
array("0001" => NULL))

Here's the rub:  I have no idea how to generate or submit a patch.  But this 
fix 
works.  If someone can turn this into a real fix and run with it, great.  If 
someone would contact me and help me turn it into a real patch, I would be 
happy 
to help.

----------------
[2012-09-12 21:56:17] brandonkirsch at gmail dot com

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


;Database=;Trusted_Connection=yes"
, ''
, ''
);

$res = odbc_exec(
  $conn
, 'SELECT SUM(1)
  FROM information_schema.tables
  WHERE 3 = 2'
);

$row = odbc_fetch_array($res);
odbc_free_result($res);
odbc_close($conn);
var_dump($row);

Expected result:

Bug #46473 [Com]: php segfaults on some queries using pdo_odbc & ibm-db2 on a 64bits platform

2013-06-26 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=46473&edit=1

 ID: 46473
 Comment by: brandonkirsch at gmail dot com
 Reported by:philippe dot marasse at ac-poitiers dot fr
 Summary:php segfaults on some queries using pdo_odbc &
 ibm-db2 on a 64bits platform
 Status: Assigned
 Type:   Bug
 Package:PDO related
 Operating System:   Linux Red Hat EL5 x86_64
 PHP Version:5.2.6
 Assigned To:iodbc
 Block user comment: N
 Private report: N

 New Comment:

I am very familiar with this problem - IT IS NOT A BUG IN PHP.

64-bit IBM iSeriesAccess ODBC drivers are built against an antiquated 
definition of what 64-bit ODBC should be. Instead, the IBM drivers use 32-bit 
values in places where 64-bits should be used.

The end result is that a 32-bit value ("-1" to represent NULL) is interpreted 
by 64-bit PHP as a large number, causing it to read an invalid memory address 
and therefore segfault.

You can ask IBM for a better ODBC driver, but they ignored us when we tried.

I have a custom patch for php_odbc.c that "fixes" the problem by hacking up PHP 
ODBC bindings to treat all ODBC SQL_NULL_DATA values as 32-bit. There are small 
potential downsides that can occur if you use this patch with a real 64-bit 
ODBC driver AND you try to access fields > 4GB.

http://www.perceptionilluminates.com/php/php_odbc.c -- It's antiquated (PHP 
5.2.17) but it is also well commented, so you can port the hack to a modern 
version if you'd like.


Previous Comments:

[2009-06-30 19:23:57] d dot stcyr at streamfoundry dot com

Was able to circumvent by configuring (now, PHP 5.2.10) with --enable-debug.  
PHP 5.2.10 without --enable-debug fails the same way as did 5.2.9.  Can someone 
advise if this is the same problem and a prognosis for correction?


[2009-06-24 15:57:26] d dot stcyr at streamfoundry dot com

I believe we have a same/similar situation running PHP 5.2.9 on 64-bit SLES10 - 
with the ibm-db2 1.8.2 pdo_odbc extension. Getting a "Child pid nnn exit signal 
Segmentation fault (11)". Here is a simple recreate script trying to connect to 
the DB2 "SAMPLE" database:



Program terminated with signal 11, Segmentation fault.
#0  _zval_ptr_dtor (zval_ptr=0x3f31c70)
at /opt/SFI/php-5.2.9/Zend/zend_execute_API.c:412
412 (*zval_ptr)->refcount--;

Backtrace:
#0  _zval_ptr_dtor (zval_ptr=0x3f31c70)
at /opt/SFI/php-5.2.9/Zend/zend_execute_API.c:412
#1  0x02a36282 in zend_do_fcall_common_helper_SPEC (
execute_data=0x3f31ec0) at /opt/SFI/php-5.2.9/Zend/zend_execute.h:155
#2  0x02a26992 in execute (op_array=0x20002bb0d90)
at /opt/SFI/php-5.2.9/Zend/zend_vm_execute.h:92
#3  0x02a032ac in zend_execute_scripts (type=,
retval=0x0, file_count=2) at /opt/SFI/php-5.2.9/Zend/zend.c:1134
#4  0x029ba4c4 in php_execute_script (primary_file=0x3f344d0)
at /opt/SFI/php-5.2.9/main/main.c:2023
#5  0x02a970c8 in php_handler (r=0x2de5ba8)
at /opt/SFI/php-5.2.9/sapi/apache2handler/sapi_apache2.c:632
#6  0x02aedce0 in ap_run_handler () from /usr/sbin/httpd2-prefork
#7  0x02af1516 in ap_invoke_handler () from /usr/sbin/httpd2-prefork
#8  0x02afccd8 in ap_process_request () from /usr/sbin/httpd2-prefork
#9  0x02afa08c in ?? () from /usr/sbin/httpd2-prefork
#10 0x02af55b4 in ap_run_process_connection ()
   from /usr/sbin/httpd2-prefork
#11 0x02b01190 in ?? () from /usr/sbin/httpd2-prefork
#12 0x02b014b0 in ?? () from /usr/sbin/httpd2-prefork
#13 0x02b0158a in ?? () from /usr/sbin/httpd2-prefork
#14 0x02b021d4 in ap_mpm_run () from /usr/sbin/httpd2-prefork
#15 0x02ad8646 in main () from /usr/sbin/httpd2-prefork

Please let me know if this falls within the known exposure of the work being 
done on this bug. And a status?

Thanks.


[2009-04-25 15:15:16] j...@php.net

iodbc: What is the status with this fix? (if this still isn't fixed, 
please update the PHP version..)


[2008-11-07 11:45:59] io...@php.net

I am working on a fix for pdo_odbc to bring it up to ODBC 3.51 API 
specification including full 64bit support, similar to the work i did on 
the regular ext/odbc code.


[2008-11-03 15:35:13] philippe dot marasse at ac-poitiers dot fr

Description:

On our both platforms (32 & 64 bits), we have php compiled with support for IBM 
DB2 database via pdo_odbc extension. We ran into unexpected segfaults deploying 
a new applicati

Bug #55291 [Com]: All ODBC Queries Return INTs as Strings For Multiple ODBC Drivers

2012-09-10 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=55291&edit=1

 ID: 55291
 Comment by: brandonkirsch at gmail dot com
 Reported by:brandonkirsch at gmail dot com
 Summary:All ODBC Queries Return INTs as Strings For Multiple
 ODBC Drivers
 Status: Not a bug
 Type:   Bug
 Package:ODBC related
 Operating System:   SUSE SLES 10 SP2
 PHP Version:5.3.6
 Block user comment: N
 Private report: N

 New Comment:

FYI - For those of you still struggling with this "Not a bug" - there are 
functions available (odbc_field_type, mssql_field_type) that can help you 
re-cast 
your database numerics back to their correct types in PHP.


Previous Comments:

[2012-02-07 08:50:56] martijntje at martijnotto dot nl

I have no idea why this bug is closed as bogus.

The current behavior is wrong for many reasons:
- Higher memory usage (can be problematic with big datasets)
- This forces one to use is_numeric instead of is_int, is_float, etc (much 
slower)
- Removed the option for strict comparison: "1" === 1 => false


[2011-12-01 05:35:08] ssuffic...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Most database layers convert numeric values to strings to preserve their 
precision as PHP does not support all numeric precisions which a database might 
(i.e. 64 bit integers). Since strings may be silently converted to numeric in 
PHP ("1" + 2 = 3), this should not pose too much of an issue.

----
[2011-07-26 21:44:49] brandonkirsch at gmail dot com

Description:

odbc_* and PDO ODBC functions are each returning SQL integer values as PHP 
strings. However, SQL NULL values properly appear as PHP NULL values.

I have tested against multiple ODBC providers (FreeTDS and iSeries Access for 
Linux).


System:

SUSE Enterprise Linux Server 10 (SP2) - 32bit

Linux dev-webhost1 2.6.16.60-0.42.5-default #1 Mon Aug 24 09:41:41 UTC 2009 
i686 
i686 i386 GNU/Linux

UnixODBC

PHP 5.3.6 from source

./configure  --with-apxs2=/usr/local/apache2/bin/apxs --with-
mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5 --with-config-
file-
path=/usr/local/php5/etc --enable-sockets --enable-soap --with-openssl --with-
unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib --with-pdo-odbc=unixODBC,/usr


Test script:
---
1. odbc_* against FreeTDS to SQL Server 2008:

$odbc = odbc_connect('hpsql3','--censored--','--censored--');
$or = odbc_exec($odbc,'SELECT 1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


2. odbc_* against iSeries Access for Linux to AS/400:

$odbc = odbc_connect('iSeriesDSN','--','--');
$or = odbc_exec($odbc,'SELECT 1 FROM SYSIBM.SYSDUMMY1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


3. PDO against FreeTDS to SQL Server 2008

$pdo = new PDO('odbc:hpsql3','--','--');
var_dump($pdo->query('SELECT 1')->fetch(PDO::FETCH_ASSOC)); // array (string 
"1")


4. PDO against iSeries Access for Linux to AS/400

$pdo = new PDO('odbc:iSeriesDSN','--','--');
var_dump($pdo->query('SELECT 1 FROM 
SYSIBM.SYSDUMMY1')->fetch(PDO::FETCH_ASSOC)); // array (string "1")

Expected result:

I expect to get arrays containing (int) 1

Actual result:
--
I actually get arrays containing (string) "1"






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55291&edit=1

Bug #61387 [Com]: NULL valued anonymous column causes segfault in odbc_fetch_array

2012-09-12 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61387&edit=1

 ID: 61387
 Comment by: brandonkirsch at gmail dot com
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


;Database=;Trusted_Connection=yes"
, ''
, ''
);

$res = odbc_exec(
  $conn
, 'SELECT SUM(1)
  FROM information_schema.tables
  WHERE 3 = 2'
);

$row = odbc_fetch_array($res);
odbc_free_result($res);
odbc_close($conn);
var_dump($row);

Expected result:

array(1) {[0]=> NULL}

or E_WARNING

Actual result:
--
segfault, apache log says:

[warn] [client x.x.x.x] (OS 109)The pipe has been ended.  : mod_fcgid: get 
overlap result error
[error] [client x.x.x.x] Premature end of script headers: foo.php
[info] mod_fcgid: process C:/Webserver/Apache2.2/php-5.3.10/php-cgi.exe(4420) 
exit(communication error), return code -1073741819

eventlog says:
Faulting application php-cgi.exe, version 5.3.10.0, faulting module php5.dll, 
version 5.3.10.0, fault address 0x000858df.

PHP itself does not produce any sort of output






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61387&edit=1

Bug #61387 [Com]: NULL valued anonymous column causes segfault in odbc_fetch_array

2012-09-12 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=61387&edit=1

 ID: 61387
 Comment by: brandonkirsch at gmail dot com
 Reported by:marec at stringdata dot cz
 Summary:NULL valued anonymous column causes segfault in
 odbc_fetch_array
 Status: Open
 Type:   Bug
 Package:ODBC related
 Operating System:   windows server 2003 R2
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

This problem is isolated to the SQL Server Native Client ODBC Driver. Most 
other 
ODBC drivers will automatically provide some type of aliased column name for 
arbitrary values that you select.

When using a SELECT 'VALUE' statement with SQL Server ODBC, the 
php_odbc_fetch_hash() function returns the column as 'VALUE' => 'VALUE' -- that 
is, the value you select is also the key in the array.

The problem occurs at the end of the php_odbc_fetch_hash() function in 
php_odbc.c (for me, on 5.2.17 it begins on line 1510) and it looks like this:

if (!*(result->values[i].name)) { // GDB says this evaluates to 1
  zend_hash_update(Z_ARRVAL_P(return_value), Z_STRVAL_P(tmp),
Z_STRLEN_P(tmp)+1, &tmp, sizeof(zval *), NULL); // SEGFAULT

This usage of zend_hash_update() causes a segfault in PHP 5.2.17 and PHP 
5.3.16.  
I guess that result->values[i].name looks legit and/or usable when it is not.

I updated the if statement to read:

if (!*(result->values[i].name) && Z_TYPE_P(tmp) != IS_NULL) { // Evaluates 
false 
for SQL NULLs that sets ZVAL_NULL(tmp)

This skips the incorrect usage of zend_hash_update with Z_STR* functions and 
proceeds to the "else" condition that handles it correctly.

For us, this solution works perfectly and the end-result is array("" => NULL) 
instead of a segfault.  Other unaliased NULL values from other databases 
continue to work the same way as before (iSeries ODBC drivers return 
array("0001" => NULL))

Here's the rub:  I have no idea how to generate or submit a patch.  But this 
fix 
works.  If someone can turn this into a real fix and run with it, great.  If 
someone would contact me and help me turn it into a real patch, I would be 
happy 
to help.


Previous Comments:
----------------
[2012-09-12 21:56:17] brandonkirsch at gmail dot com

I've been fighting with this bug all day long on PHP 5.2.17 *AND* PHP 5.3.16 
for 
64-bit Linux.

I have isolated the problem to odbc_fetch_array() for result sets that contain 
an anonymous (unnamed) column with a NULL value. If NULL value is aliased 
("SELECT NULL as SOMETHING") there is no crash.  If an anonymous (unnamed) 
column contains anything other than NULL, there is no crash.

Test Script:

$sql = 'SELECT NULL';

$c = odbc_connect('Driver=SQL Server Native Client 
11.0;server=hpesc1;uid=xxx;pwd=xxx;Database=xxx','','');

$e = odbc_exec($c, $sql);

$row = odbc_fetch_array($e);


Here are different combinations of SQL that will or won't crash PHP:

$sql = 'SELECT NULL'; // PHP SEGFAULT
$sql = 'SELECT NULL as [one]'; // OK
$sql = 'SELECT 1'; // OK
$sql = 'SELECT 1, NULL'; // SEGFAULT
$sql = 'SELECT 1, NULL as [two]'; // OK

And a backtrace:


#0  zend_inline_hash_func (nKeyLength=, arKey=0x0) at 
/usr/src/php-5.3.16/Zend/zend_hash.h:283
#1  _zend_hash_add_or_update (ht=0xfce8b8, arKey=0x0, nKeyLength=1, 
pData=0x7fffab90, nDataSize=8, pDest=0x0, flag=1) at /usr/src/php-
5.3.16/Zend/zend_hash.c:218
#2  0x0057528f in php_odbc_fetch_hash (ht=, 
return_value=0xfccfe8, result_type=2, return_value_ptr=, 
this_ptr=, 
return_value_used=) at /usr/src/php-
5.3.16/ext/odbc/php_odbc.c:1775


My comprehension of C & the PHP source code is very limited, but it looks like 
php_odbc.c lines 1752 (handling of SQL_NULL_DATA) and 1771 through 1779 are 
suspect.  I think php_odbc.c may be using zend_hash_update improperly but I 
can't tell for sure.

And finally, here is a workaround script that DOES NOT segfault:


;Database=;Trusted_Connection=yes"
, ''
, ''
);

$res = odbc_exec(
  $conn
, 'SELECT SUM(1)
  FROM information_schema.tables
  WHERE 3 = 2'
);

$row = odbc_fetch_array($res);
odbc_free_result($res);
odbc_close($conn);
var_dump($row);

Expected result:

array(1) {[0]=> NULL}

or E_WARNING

Actual result:
--
segfault, apache log says:

[warn] [client x.x.x.x] (OS 109)The pipe has been ended.  : mod_fcgid: get 
overlap result error
[error] [client x.x.x.x] Premature end of script headers: foo.php
[info] mod_fcgid: process C:/Webserver/Apache2.2/php-5.3.10/php-cgi.exe(4420) 
exit(communication error), return code -1073741819

eventlog says:
Faulting application php-cgi.exe, version 5.3.10.0,

[PHP-BUG] Bug #53116 [NEW]: libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2

2010-10-20 Thread brandonkirsch at gmail dot com 
From: 
Operating system: Linux
PHP version:  5.3.3
Package:  Compile Failure
Bug Type: Bug
Bug description:libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2

Description:

Trying to update to PHP 5.3.3 from 5.2 and libphp5.so will not build.



I have no problems using the same configure command for php 5.3.2 -
Something has 

changed between 5.3.2 and 5.3.3



I receive the following error only when building 5.3.3:



** ** ** Warning: inter-library dependencies are not known to be supported.
** ** 

** All declared inter-library dependencies are being dropped.



** ** ** Warning: libtool could not satisfy all declared inter-library **
** ** 

dependencies of module libphp5. Therefore, libtool will create ** ** ** a
static 

module, that should work as long as the dlopening ** ** ** application is
linked 

with the -dlopen flag. copying selected object files to avoid basename
conflicts.

Test script:
---
PHP 5.3.2:



./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5
--with-config-file-path=/usr/local/php5/etc --enable-sockets --enable-soap
--with-openssl --with-unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib
--with-pdo-odbc=unixODBC,/usr --with-pdo-dblib=/usr/local/freetds



Works perfectly, builds libphp5.so and copies into my Apache 2.2 modules
path.



PHP 5.3.3:



./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5
--with-config-file-path=/usr/local/php5/etc --enable-sockets --enable-soap
--with-openssl --with-unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib
--with-pdo-odbc=unixODBC,/usr --with-pdo-dblib=/usr/local/freetds



Same command, throws an error, does not build libphp5.so

Expected result:

I expect 5.3.3 to build libphp5.so as 5.3.2 does.

Actual result:
--
** ** ** Warning: inter-library dependencies are not known to be supported.
** ** 

** All declared inter-library dependencies are being dropped.



** ** ** Warning: libtool could not satisfy all declared inter-library **
** ** 

dependencies of module libphp5. Therefore, libtool will create ** ** ** a
static 

module, that should work as long as the dlopening ** ** ** application is
linked 

with the -dlopen flag. copying selected object files to avoid basename
conflicts.

-- 
Edit bug report at http://bugs.php.net/bug.php?id=53116&edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53116&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53116&r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=53116&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53116&r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=53116&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53116&r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=53116&r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=53116&r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=53116&r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=53116&r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=53116&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=53116&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=53116&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53116&r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=53116&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53116&r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=53116&r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=53116&r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=53116&r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=53116&r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=53116&r=mysqlcfg

Bug #53116 [Fbk->Opn]: libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2

2010-10-20 Thread brandonkirsch at gmail dot com 
Edit report at http://bugs.php.net/bug.php?id=53116&edit=1

 ID: 53116
 User updated by:brandonkirsch at gmail dot com
 Reported by:brandonkirsch at gmail dot com
 Summary:libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2
-Status: Feedback
+Status: Open
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N

 New Comment:

SUSE Linux Enterprise Server 10 SP2



The libraries I am linking to with PHPs 'configure' are:

Apache httpd 2.2.9 (from source)

Freetds 0.82 (from source)

OpenSSL 0.9.8a (SLES RPM, includes "0.9.7g" compatibility module)

unixODBC 2.2.11 (SLES)

gd 2.0.32 (SLES)

libjpeg 6.2.0 (SLES)


Previous Comments:

[2010-10-20 18:07:35] paj...@php.net

Which distributions do you use? and its version?

----
[2010-10-20 18:01:10] brandonkirsch at gmail dot com

Description:

Trying to update to PHP 5.3.3 from 5.2 and libphp5.so will not build.



I have no problems using the same configure command for php 5.3.2 -
Something has 

changed between 5.3.2 and 5.3.3



I receive the following error only when building 5.3.3:



** ** ** Warning: inter-library dependencies are not known to be
supported. ** ** 

** All declared inter-library dependencies are being dropped.



** ** ** Warning: libtool could not satisfy all declared inter-library
** ** ** 

dependencies of module libphp5. Therefore, libtool will create ** ** **
a static 

module, that should work as long as the dlopening ** ** ** application
is linked 

with the -dlopen flag. copying selected object files to avoid basename
conflicts.

Test script:
---
PHP 5.3.2:



./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5
--with-config-file-path=/usr/local/php5/etc --enable-sockets
--enable-soap --with-openssl --with-unixODBC=/usr --with-gd
--with-jpeg-dir=/usr/lib --with-pdo-odbc=unixODBC,/usr
--with-pdo-dblib=/usr/local/freetds



Works perfectly, builds libphp5.so and copies into my Apache 2.2 modules
path.



PHP 5.3.3:



./configure --with-apxs2=/usr/local/apache2/bin/apxs
--with-mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5
--with-config-file-path=/usr/local/php5/etc --enable-sockets
--enable-soap --with-openssl --with-unixODBC=/usr --with-gd
--with-jpeg-dir=/usr/lib --with-pdo-odbc=unixODBC,/usr
--with-pdo-dblib=/usr/local/freetds



Same command, throws an error, does not build libphp5.so

Expected result:

I expect 5.3.3 to build libphp5.so as 5.3.2 does.

Actual result:
--
** ** ** Warning: inter-library dependencies are not known to be
supported. ** ** 

** All declared inter-library dependencies are being dropped.



** ** ** Warning: libtool could not satisfy all declared inter-library
** ** ** 

dependencies of module libphp5. Therefore, libtool will create ** ** **
a static 

module, that should work as long as the dlopening ** ** ** application
is linked 

with the -dlopen flag. copying selected object files to avoid basename
conflicts.






-- 
Edit this bug report at http://bugs.php.net/bug.php?id=53116&edit=1

[PHP-BUG] Bug #55291 [NEW]: All ODBC Queries Return INTs as Strings For Multiple ODBC Drivers

2011-07-26 Thread brandonkirsch at gmail dot com 
From: 
Operating system: SUSE SLES 10 SP2
PHP version:  5.3.6
Package:  ODBC related
Bug Type: Bug
Bug description:All ODBC Queries Return INTs as Strings For Multiple ODBC 
Drivers

Description:

odbc_* and PDO ODBC functions are each returning SQL integer values as PHP

strings. However, SQL NULL values properly appear as PHP NULL values.

I have tested against multiple ODBC providers (FreeTDS and iSeries Access
for 
Linux).


System:

SUSE Enterprise Linux Server 10 (SP2) - 32bit

Linux dev-webhost1 2.6.16.60-0.42.5-default #1 Mon Aug 24 09:41:41 UTC 2009
i686 
i686 i386 GNU/Linux

UnixODBC

PHP 5.3.6 from source

./configure  --with-apxs2=/usr/local/apache2/bin/apxs --with-
mssql=/usr/local/freetds --with-ldap --prefix=/usr/local/php5
--with-config-
file-
path=/usr/local/php5/etc --enable-sockets --enable-soap --with-openssl
--with-
unixODBC=/usr --with-gd --with-jpeg-dir=/usr/lib
--with-pdo-odbc=unixODBC,/usr


Test script:
---
1. odbc_* against FreeTDS to SQL Server 2008:

$odbc = odbc_connect('hpsql3','--censored--','--censored--');
$or = odbc_exec($odbc,'SELECT 1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


2. odbc_* against iSeries Access for Linux to AS/400:

$odbc = odbc_connect('iSeriesDSN','--','--');
$or = odbc_exec($odbc,'SELECT 1 FROM SYSIBM.SYSDUMMY1');
var_dump(odbc_fetch_array($or)); // array( string "1" )


3. PDO against FreeTDS to SQL Server 2008

$pdo = new PDO('odbc:hpsql3','--','--');
var_dump($pdo->query('SELECT 1')->fetch(PDO::FETCH_ASSOC)); // array
(string "1")


4. PDO against iSeries Access for Linux to AS/400

$pdo = new PDO('odbc:iSeriesDSN','--','--');
var_dump($pdo->query('SELECT 1 FROM
SYSIBM.SYSDUMMY1')->fetch(PDO::FETCH_ASSOC)); // array (string "1")

Expected result:

I expect to get arrays containing (int) 1

Actual result:
--
I actually get arrays containing (string) "1"

-- 
Edit bug report at https://bugs.php.net/bug.php?id=55291&edit=1
-- 
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55291&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55291&r=trysnapshot53
Try a snapshot (trunk):  
https://bugs.php.net/fix.php?id=55291&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55291&r=fixed
Fixed in SVN and need be documented: 
https://bugs.php.net/fix.php?id=55291&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55291&r=alreadyfixed
Need backtrace:  
https://bugs.php.net/fix.php?id=55291&r=needtrace
Need Reproduce Script:   
https://bugs.php.net/fix.php?id=55291&r=needscript
Try newer version:   
https://bugs.php.net/fix.php?id=55291&r=oldversion
Not developer issue: 
https://bugs.php.net/fix.php?id=55291&r=support
Expected behavior:   
https://bugs.php.net/fix.php?id=55291&r=notwrong
Not enough info: 
https://bugs.php.net/fix.php?id=55291&r=notenoughinfo
Submitted twice: 
https://bugs.php.net/fix.php?id=55291&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55291&r=globals
PHP 4 support discontinued:  
https://bugs.php.net/fix.php?id=55291&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55291&r=dst
IIS Stability:   
https://bugs.php.net/fix.php?id=55291&r=isapi
Install GNU Sed: 
https://bugs.php.net/fix.php?id=55291&r=gnused
Floating point limitations:  
https://bugs.php.net/fix.php?id=55291&r=float
No Zend Extensions:  
https://bugs.php.net/fix.php?id=55291&r=nozend
MySQL Configuration Error:   
https://bugs.php.net/fix.php?id=55291&r=mysqlcfg

Bug #53116 [Bgs]: libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2

2011-11-18 Thread brandonkirsch at gmail dot com 
Edit report at https://bugs.php.net/bug.php?id=53116&edit=1

 ID: 53116
 User updated by:brandonkirsch at gmail dot com
 Reported by:brandonkirsch at gmail dot com
 Summary:libphp5.so Will Not Build in 5.3.3 - Builds in 5.3.2
 Status: Bogus
 Type:   Bug
 Package:Compile Failure
 Operating System:   Linux
 PHP Version:5.3.3
 Block user comment: N
 Private report: N

 New Comment:

There's nothing bogus about this bug report, unless bogus is the new "Won't 
Fix."


Previous Comments:

[2011-11-16 14:18:22] fel...@php.net

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.




[2010-10-25 09:28:59] rayro at gmx dot de

maybe related to #52419


[2010-10-21 14:55:51] rayro at gmx dot de

I installed an ubuntu server 10.04 in virtual box and tested 5.3.3 installation 
(and wanted to test fpm).
Anything goes wrong, got some of the same errors like the Brandon K..

my configuration test is as follows:


root@ape:/usr/local/src/php/php-5.3.3# ./configure \
--prefix=/usr/local/php-5.3.3 \
--enable-bcmath \
--enable-mbstring \
--enable-exif \
--enable-calendar \
--enable-ftp \
--enable-mbstring \
--enable-zip \
--enable-gd-native-ttf \
--enable-sockets \
--enable-pcntl \
--enable-soap \
--enable-dba \
--enable-wddx \
--enable-zend-multibyte \
--enable-sqlite-utf8 \
--enable-sysvmsg \
--enable-sysvsem \
--enable-sysvshm \
--enable-shmop \
--enable-wddx \
--enable-tokenizer \
--with-pic \
--with-zlib \
--with-pcre-regex \
--with-bz2 \
--with-gettext \
--with-openssl \
--with-apxs2=/usr/local/apache-2.2.16/bin/apxs \
--with-mysql \
--with-mysqli \
--with-pgsql \
--with-tidy \
--with-curl \
--with-curlwrappers \
--with-openssl-dir \
--with-pdo-pgsql \
--with-pdo-mysql \
--with-xsl \
--with-ldap \
--with-xmlrpc \
--with-mcrypt \
--with-mhash \
--with-gd \
--with-pear \
--with-iconv \
--with-libevent-dir \
--with-iconv-dir \
--with-jpeg-dir \
--with-png-dir \
--with-xpm-dir \
--with-freetype-dir \
--with-libexpat-dir \
--with-imap \
--with-imap-ssl \
--with-kerberos

root@ape:/usr/local/src/php/php-5.3.3# make clean && make

~
*** Warning: inter-library dependencies are not known to be supported.
*** All declared inter-library dependencies are being dropped.
*** Warning: libtool could not satisfy all declared inter-library
*** dependencies of module libphp5.  Therefore, libtool will create
*** a static module, that should work as long as the dlopening
*** application is linked with the -dlopen flag.
~

root@ape:/usr/local/src/php/php-5.3.3# cat config.log |egrep "error|undefined"

~
/usr/local/src/php/php-5.3.3/configure:15588: undefined reference to 
`yp_get_default_domain'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:15634: undefined reference to 
`__yp_get_default_domain'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:15846: undefined reference to `dlopen'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:15892: undefined reference to `__dlopen'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89174: undefined reference to 
`res_nsearch'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89709: undefined reference to 
`dns_search'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89755: undefined reference to 
`__dns_search'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89814: undefined reference to 
`dns_search'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89853: undefined reference to 
`__dns_search'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89950: undefined reference to 
`dns_search'
/* Override any gcc2 internal prototype to avoid an error.  */
/usr/local/src/php/php-5.3.3/configure:89989: undefined reference to 
`__dns_search'
/* Override any gcc2 internal prototype to avoid