[fw-mvc] A very, very strange behavior: __toString() and DbMetaData Cache relation?

Hi everyone,

I know this problem may have nothing to do with the Zend Framework in
itself but, we're struggling with a strange PHP behavior since yesterday
and so far, we've been unable to find the root cause.
Here's the general organization of the incriminated code:

abstract class A {
public function render() {
... do a lot of things including chatting with the db ...
return (string) $result;
}
public function __toString() {
return $this->render();
}
}

class B extends A {
public function render() {
... do something ....
return parent::render();
}
}

And here's the problem:
* This one entirely crashes Apache with a segfault :

$b = new B();
echo $b->render();

* Whereas this one works :

$b = new B();
echo $b;

*This is a total non-sense*, the only difference between the two is that
we're using the __toString() method instead of calling the render() one.
But the __toString() is *only* calling the render()...

What's *really* strange however, is that both work perfectly when we
disable the DbMetaData Cache of the framework or when we clean the cache
files. Here's how we configured it:

$frontendOptions = array(
'automatic_serialization' => true
);
$backendOptions = array(
'cache_dir' => ROOT_DIR.'/data/cache/dbmetadata'
);
$cache = Zend_Cache::factory(
'Core',
'File',
$frontendOptions,
$backendOptions
);
Zend_Db_Table_Abstract::setDefaultMetadataCache($cache);

More precisely, it works when we disable one particular cache file
concerning one particular table that doesn't seem to have anything
wrong. The data in the cache file is unserializable and seems OK.

That seems particularily crazy, what could be the relation between some
__toString() method and some particular DbMetaData Cache? Could anyone
give us some insight? We'll continue to dig the problem and will report
if something new pops up. But in the meantime, we'd really appreciate
some help... We might have done something wrong in the process though,
that's why we're asking for some advice.

Regards,
- Nicolas Grevet