[Fwd: Re: FreeBSD Port: php5-mysqli-5.0.4_1]

Oliver Schonrock oliver.schonrock at realtsp.com
Sun May 1 12:42:35 PDT 2005

furher information in reply to Uzi from ports maintainers.

-------- Original Message --------
Subject: Re: FreeBSD Port: php5-mysqli-5.0.4_1
Date: Sun, 01 May 2005 16:14:59 +0100
From: Oliver Schonrock <oliver.schonrock at realtsp.com>
To: Uzi Klein <uzi at bmby.com>
CC: ports at freebsd.org
References: <4274B75C.2010203 at realtsp.com> <4274C11E.4020308 at bmby.com>

please see below:

I apologise for the long email in advance. I have tried to provide
information that is as complete as possible.

Thanks very much for your help.

Oliver Schonrock

Uzi Klein wrote:
> Oliver Schonrock wrote:
> ...
>> Hi
>> We run 4 FreeBSD servers now and have just built first FBSD server on 
>> AMD64. Everything went quite smoothly using the amd64 version of freebsd.
>> until...
>> I tried to use the mysqli extension in php5.0.4 on apache 1.3.33 
>> connecting to mysql-server-4.1.11 (all built from cvsup'd ports tree).
>> in php mysql_connect() works ok, but the mysql_fetch_array() segfaults.
>> this simple php script produces the error every time (via apache or 
>> with command line binary):
>> <?php
>> $db = new mysqli('localhost', 'root', 'mysqlrootpw', 'mysql');
>> $result = $db->query('select * from user;');
>> while ($row = $result->fetch_array(MYSQLI_ASSOC))
>> {
>>   print_r($row);
>> }
>> ?>
>> => Segmentation fault (core dumped)
> I have seen mysql 4.1x dies with queries that runs fine under 4.0x. 
> Could it be that?

not really, since:
a) out application/queries are running fine under 4.1.11 on i386 (Athlon
and Pentium) hardware
b) the trivial select query in the script above should be fine on either
c) the query above runs fine when I use the mysql extension as in this

oliver at pakiri$ cat phpmysqltest.php

$db = mysql_connect('localhost', 'root', 'xWATdHcF');

if (!$db) {
    die('Could not connect: ' . mysql_error());

if (!mysql_select_db("mysql", $db)) {
    echo "Unable to select mydbname: " . mysql_error();

$result = mysql_query('select * from user;');

while ($row = mysql_fetch_assoc($result))


... gives sensible output without errors. So that would indicate to me
that the query is fine for the server, but may be causing the client
library to crash when the data is retrieved with mysql_fetch_...(). Both
php extensions (mysql and mysqli) are linked against the mysql41-client
libraries as this shows:

root at pakiri# cd /usr/ports/databases/mysql
root at pakiri# make deinstall
===>  Deinstalling for databases/mysql41-client
===>   Deinstalling mysql-client-4.1.11_1
pkg_delete: package 'mysql-client-4.1.11_1' is required by these other
and may not be deinstalled (but I'll delete it anyway):
pkg_delete: unable to completely remove directory '/usr/local/lib/mysql'
pkg_delete: unable to completely remove directory '/usr/local/share/mysql'
pkg_delete: couldn't entirely delete package (perhaps the packing list is
incorrectly specified?)

Anyway it is a requirement that both extensions (mysql and mysqli) use
the same client libraries as stated here:

and they won't build unless you are using the same client library for
both as the makefile checks for this.

So my current guess to the source of the problem is somewhere around
where the php5-mysqli extension maps the mysql41-client api into php.
Does that make sense to you given this info?

> What application gives you the sig 11? is it apache or mysql?
> Please attach relevant log files etc.

When I run the above script from the command line with:
oliver at pakiri$ php phpmysqlitest.php

I get the following in /var/log/messages:
root at pakiri# tail -f messages
May  1 16:27:45 pakiri kernel: pid 91764 (php), uid 1003: exited on
signal 11 (core dumped)

when I hit that script over the web via apache I get:
May  1 16:27:54 pakiri kernel: pid 29441 (httpd), uid 80: exited on
signal 11

So I looks like in either case that it is the php binary (or more
precisely the php5-mysqli extension) that is causing the "signal 11".

I hope this helps in diagnosis.

Thanks again.

More information about the freebsd-amd64 mailing list