php5: calling curl_version() results in bus error

[joe@…]

Most curl functions seem to work normally from php. However, calling curl_version() in a script doesn't work. When called from /opt/local/bin/php, the result is 'Bus error'. When called via FCGI, the php backend dies without output.

OS X 10.4

$ port
MacPorts 1.520

$ /opt/local/bin/php -v
PHP 5.2.5 (cli) (built: Nov 13 2007 18:23:58) 

$ /opt/local/bin/curl -V
curl 7.17.1 (i386-apple-darwin8.10.1) libcurl/7.17.1 zlib/1.2.3
Protocols: tftp ftp telnet dict http file 
Features: Largefile libz 

[ryandesign (Ryan Carsten Schmidt)]

curl_version() seems to return an array, not a string, and it works fine for me, on a MacBook Pro, with Mac OS X 10.4.11, Xcode 2.4.1, MacPorts 1.6.0-rc3, php5 5.2.5_1 and curl 7.17.1_0.

$ /opt/local/bin/php -r 'print_r(curl_version());'
Array
(
    [version_number] => 463105
    [age] => 3
    [features] => 540
    [ssl_version_number] => 0
    [version] => 7.17.1
    [host] => i386-apple-darwin8.10.1
    [ssl_version] => OpenSSL/0.9.8g
    [libz_version] => 1.2.3
    [protocols] => Array
        (
            [0] => tftp
            [1] => ftp
            [2] => telnet
            [3] => dict
            [4] => http
            [5] => file
            [6] => https
            [7] => ftps
        )

)
$

Does this work for you?

[joe@…]

Same problem as before. 10.4.11 on a MacBook, Xcode 2.4.1

$ /opt/local/bin/php -r 'print_r(curl_version());'
Bus error

[ryandesign (Ryan Carsten Schmidt)]

Curious. That should not be! Can you try rebuilding curl and then php5, and then try using curl_version() again?

sudo port -ncuf upgrade curl
sudo port -ncuf upgrade php5

[joe@…]

No luck, I'm afraid:

$ sudo port -ncuf upgrade curl
Password:
--->  Fetching curl
--->  Verifying checksum(s) for curl
--->  Extracting curl
--->  Configuring curl
--->  Building curl with target all
--->  Staging curl into destroot
--->  Unable to uninstall curl 7.17.1_0+darwin_8, the following ports depend on it:
--->    php5
--->    gimp2
--->    php5
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating curl 7.17.1_0+darwin_8
--->  Uninstalling curl 7.17.1_0+darwin_8
--->  Installing curl 7.17.1_0+darwin_8
--->  Activating curl 7.17.1_0+darwin_8
--->  Cleaning curl
$ sudo port -ncuf upgrade php5
--->  Fetching php5
--->  Verifying checksum(s) for php5
--->  Extracting php5
--->  Configuring php5
--->  Building php5 with target all
--->  Staging php5 into destroot
--->  Unable to uninstall php5 5.2.5_1+darwin_8+fastcgi+macosx+mysql5+pear, the following ports depend on it:
--->    php5-xdebug
Warning: Uninstall forced.  Proceeding despite dependencies.
--->  Deactivating php5 5.2.5_1+darwin_8+fastcgi+macosx+mysql5+pear
--->  Uninstalling php5 5.2.5_1+darwin_8+fastcgi+macosx+mysql5+pear
--->  Installing php5 5.2.5_1+darwin_8+fastcgi+macosx+mysql5+pear

If this is your first install, you might want
--->  Activating php5 5.2.5_1+darwin_8+fastcgi+macosx+mysql5+pear
--->  Cleaning php5
$ /opt/local/bin/php -r 'print_r(curl_version());'
Bus error

[ryandesign (Ryan Carsten Schmidt)]

Maybe there's something weird in your configuration? Try backing up your php.ini, then replacing it with php.ini-recommended which is included in the php5 port.

I'm also not sure about this php5-xdebug. But if that's an extension that you load by adding a line to your php.ini, then trying php.ini-recommended should rule that out as well.

[joe@…]

php5-xdebug is, in fact, an extension loaded by a zend_extension line in php.ini

Unfortunately, running /opt/local/bin/php -r 'print_r(curl_version());' with php.ini-recommended moved to php.ini still produces the bus error.

[nick-macosforge@…]

I'm seeing this same problem on Leopard (10.5.1) with php5 @5.2.5_1 and curl @7.17.1_0. Anything else that might be of use to try to debug this? Where are the logs from the build of a port stored? Maybe php5 can't find curl for some reason. Thanks!

[ryandesign (Ryan Carsten Schmidt)]

Nick, MacPorts stores no logs. You could "sudo port -ncufdv upgrade php5" to see the complete build output. You could send everything to a file with "sudo port -ncufdv upgrade php5 &>php5.log" and then examine php5.log for anything curl-related.

Do either of you have anything in /usr/local/lib? If so, try moving /usr/local aside (rename it to /usr/local-off) and reinstall curl and php5 again.

Or, do either of you have Fink installed? Anything in /sw/lib?

Or, do either of you have DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH set?

[joe@…]

Do either of you have anything in /usr/local/lib? If so, try moving /usr/local aside (rename it to /usr/local-off) and reinstall curl and php5 again.

$ ls /usr/local
ls: /usr/local: No such file or directory

Or, do either of you have Fink installed? Anything in /sw/lib?

Never installed Fink.

$ ls /sw
ls: /sw: No such file or directory

Or, do either of you have DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH set?

$ echo $DYLD_LIBRARY_PATH

$ echo $DYLD_FALLBACK_LIBRARY_PATH

[gage@…]

Has this issue of bus errors occuring when both apache2 and curl are in use been resolved? I am experiencing the same problem when running perl scripts. Scripts that include system calls to curl or to lwp-request cause a bus error.

I am running Leopard (10.5.4) on macbook and am using the apache2, curl and lwp-request downloaded from macports.

Another description of this problem is at ​http://webwork.maa.org/moodle/mod/forum/discuss.php?d=6043

I have seen similar reports dating from November 2007 about macports and the (then new ) leopard installation. I have also seen reports from debian builds from earlier years that were fixed by "upgrading to the newest release". Unfortunately I wasn't able to find any details about the fix.

Thank you for your attention.

Take care,

Mike Gage

21. of Rochester

[ryandesign (Ryan Carsten Schmidt)]

Replying to gage@math.rochester.edu:

Has this issue of bus errors occuring when both apache2 and curl are in use been resolved? I am experiencing the same problem when running perl scripts. Scripts that include system calls to curl or to lwp-request cause a bus error.

I still cannot reproduce this problem on my systems, either with 10.4.11 or 10.5.4. If you can attach a minimal perl script which I can run on my systems to see the problem, I can attempt to look into this further.

[blb@…]

Is anyone still seeing this, I can't reproduce either? If it is still an issue for someone, interesting information would include the output from

otool -L /opt/local/bin/php

and

otool -L /opt/local/lib/libcurl.dylib

[joe@…]

Replying to blb@…:

Is anyone still seeing this, I can't reproduce either?

I'm still seeing this on my Tiger system. Here's the otool output:

$ otool -L /opt/local/bin/php
/opt/local/bin/php:
        /opt/local/lib/libexslt.0.dylib (compatibility version 9.0.0, current version 9.13.0)
        /opt/local/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
        /opt/local/lib/libsqlite3.0.dylib (compatibility version 9.0.0, current version 9.6.0)
        /usr/lib/libiodbc.2.dylib (compatibility version 4.0.0, current version 4.10.0)
        /opt/local/lib/mysql5/mysql/libmysqlclient.15.dylib (compatibility version 16.0.0, current version 16.0.0)
        /opt/local/lib/libmhash.2.dylib (compatibility version 3.0.0, current version 3.1.0)
        /opt/local/lib/libmcrypt.4.dylib (compatibility version 9.0.0, current version 9.8.0)
        /opt/local/lib/libltdl.3.dylib (compatibility version 5.0.0, current version 5.5.0)
        /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP (compatibility version 1.0.0, current version 2.2.0)
        /opt/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0)
        /opt/local/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.16.0)
        /opt/local/lib/libpng12.0.dylib (compatibility version 24.0.0, current version 24.0.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
        /opt/local/lib/libjpeg.62.dylib (compatibility version 63.0.0, current version 63.0.0)
        /opt/local/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
        /opt/local/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
        /opt/local/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.1.0)
        /opt/local/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.4)
        /opt/local/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9)
        /opt/local/lib/libxml2.2.dylib (compatibility version 9.0.0, current version 9.30.0)
        /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos (compatibility version 5.0.0, current version 5.0.0)
        /opt/local/lib/libxslt.1.dylib (compatibility version 3.0.0, current version 3.22.0)

$ otool -L /opt/local/lib/libcurl.dylib
/opt/local/lib/libcurl.dylib:
        /opt/local/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.1.0)
        /opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.9)

[blb@…]

Replying to joe@…:

I'm still seeing this on my Tiger system. Here's the otool output:

...

Okay, that shows php is linked to the right curl library, and the curl library doesn't have anything odd going on with it. Your curl port may be a bit outdated, but I'm not sure that's the actual cause of the problem.

[(none)]

Milestone Port Bugs deleted

[jmroot (Joshua Root)]

Do you still see this now that php5-curl is a separate port?

[ryandesign (Ryan Carsten Schmidt)]

Mike sent the following response by email:

I am no longer seeing this behavior using perl and perl scripts and the curl port in MacPorts.

But that of course doesn't tell us whether a problem remains with php and curl.

[joe@…]

As of MacPorts 1.8.2, running on OX X 10.6, I'm no longer seeing the bus error. Running

/opt/local/bin/php -r 'print_r(curl_version());'

now performs as expected.

[ryandesign (Ryan Carsten Schmidt)]

I tested on two systems and it still works for me too. Guess we'll call it fixed.