HEEEEEEEELP!

Anon

Hello everyone,

I'm getting more and more desperate.

Since yesterday, a script that was working perfectly started giving me:

Fatal error: Cannot use assign-op operators with overloaded objects nor string offsets in file xxx on line yyy.

The weird thing is that it doesn't always happen, and there really is nothing particular over there.

Essentially, we're inside a for loop, and there are a few string concatenations (it seems to always happen on a line with a . ).

This is on a Linux 6.2 server with Apache 1.13.19 and php4.0.6.

I'd appreciate any help or thoughts. I'm pretty sure my code is bug-free.

Martin

calevans

It would help if we could see a sample of the code that's blowing chow.

Cal

Cal Evans
- Senior Internet Dreamer
- Techno-Mage
- Last of the great Internet Burma-Shave poets.
http://www.calevans.com
*

Anon

Hello Cal,

that's just the thing; the code is rather simple and goes something like:

$table[$i] .= " ...whatever ....
....
.... " . my_function(hello) . " ...whatever
...
...";

The weird thing is that it used to work without a problem, and now it sometimes does, sometimes doesn't.

It seems doing "apachectl restart" helps for a little while, but after a few minutes/hours, the problem comes back.

Just as a test, I even replaced my code with simple things like

$table[$i] .= " ";

--and the problem would still sometimes show up (of course, the part where it actually dies can be simple, which doesn't mean the surrounding parts are -- but again, the code sometimes works, sometimes doesn't, which to me points to a problem elsewhere...?)

Thanks for any insight...

Martin

[deleted]

A search on google shows this error appears more often when adding strings to an element of an array.

A simple workaround:
$sTemp = $aMyArray[$iIndex];
$sTemp .= 'foobar';
$aMyArray[$iIndex]=$sTemp;

Anon

Wow, that looks to be a fun one.

Ok, have you looked at what else may have changed (however insignificant it may seem) on the box? Apache and PHP rely on a lot of linked libraries. Have you loaded ANYTHING on the box recently? Also, have you considered updating to the latest Apache? Not sure it would do any good, but it's a thought.

Cal

Cal Evans
Senior Internet Dreamer
http://www.calevans.com
*

Anon

Hi again Cal,

the only thing I can think of is:

we installed a Thawte certificate for another site recently
(but I tried running the server w/out SSL -- same problem).

I also deleted old httpd.mm.xxxx files from the log directory.

I looked at the Zend code, and it seems this error is returned when a variable pointer doesn't exist (and honestly, I am not that familiar with C++):

binary_assign_op_addr: {
zval **var_ptr = get_zval_ptr_ptr(&opline->op1, Ts, BP_VAR_RW);

if (!var_ptr) {
zend_error(E_ERROR, "Cannot use assign-op operators with overloaded objects nor string ....blah blah}

Could it be a memory problem of some kind?

Anon

Hi Vincent,

funny I tried a search on Google and only came up with a couple of German links...

I'll give this approach a try, but the question still remains: why is this happening now, and is it a Zend/PHP bug?

Thanks!

Martin

Anon

Hello Vincent and Cal,

thanks for taking some time to answer my question.

Looks like Vincent's solution works. I can't say I like it because it "uglifies" my code, but it's better than a down site.

I'm still curious as to why this started happening (I'll upgrade to Apache 1.3.22 and re-test, just to see), and whether PHP developers should be made aware of this. Can we assume this is a PHP bug?

Martin

Anon

A quick search on Google lead me to this page... I have the same problem... what it seems to be (at the first glance) is that it doesn't know whether $var[$i] is an element of the $var array or you're trying to reffer to the $i char of the string $var 🙂 (hope it makes sense for you). So if you declare it (as a php programmer we're not really used to this word, aren't we) $var = array() prior to using it it's ok. It works.

Anon

Martin,

Geecu's solution worked for me. I had the same problem - code suddenly stopped working and could see nothing even slightly likely to go wrong. The notion that it might be related to pointers seems consistent with the solution being to declare the array before using it.