fbsql_free_result().

This function appears to be of critical importance. If
you are experiencing random hangs and crashes in your scripts, suspect a lack of fbsql_free_result().
It appears that failure to explicitly release a result set causes memory problems, usually manifested by Apache segfaulting. With FrontBase < 3.4, this caused us very serious problems as locks were not being released, resulting in a stalled database. With 3.4/3.5, this no longer happens, but nonetheless the httpd child dies, which means that pages are only partially output, and also impacts on performance. I don't know the internals of the fbsql PHP driver and don't have time to investigate further. I would suspect a bug in how cleanup in the garbage collector is implemented, possibly leading to attempts to free the same memory block twice, or an attempt to free a block with a bad pointer (although that would be more likely to yield a SIGBUS, at least occasionally, and we have only seen SIGSEGV). Simply using fbsql_free_result() without knowing exactly what is causing the problem might look like voodoo, but we have found it to be voodoo that works.

A typical FrontBase session might look like this:

$fbdc=fbsql_connect($DBServer,$DBUser,$DBPass) or die("Could not connect to db"); 
$cok=fbsql_select_db($DBName);
if(!$cok)
 {
 echo "<P>DB select failed</P>\n";
 die();
 }

$qstr="select * from products where qty_on_hand < 25;";

$oresult=fbsql_query($qstr,$fbdc);

if($oresult===false)
 {
 echo "<P>Query [$qstr] failed: ".fbsql_errno().": ".fbsql_error()."</P>\n";
 die();
 }

do
 {
 $orow=fbsql_fetch_row($oresult);
 if($orow!==false)
  {
  ...
  ...
  }
 }while($orow!==false);

fbsql_free_result($oresult); <--- THIS IS CRITICAL

fbsql_close($fbdc);

It is a big job to go back through a large set of scripts and retrofit this code. Although the manual states it should not be necessary, it would appear prudent to use this call in new code.

David Gillies
San Jose
Costa Rica