Smarty

[Mastershrimp]

Hi,

I'm afraid but I think that topic is gonna last a while - at least the problem seems really random to me. I can hardly reproduce it at all. Anyways. I'll dive right into it:

Scenario:
In the past weeks I primarily developed on my local machine (Win7, PHP5.2.8 on an XAMPP). Therefore I updated Smarty (3.0 -> 3.1) only locally at first. That worked more or less smoothly and in the end I got it running successfully.

Now I decided to update a semi-productive system with the so-far working state from my local machine. And that's when the fun began.

You know, I use Smarty for all backend files. So, I was able to open the index page of the backend (very simple template). However, opening another more complex backend page (that includes another template using {include file="filename.tpl"}) crashed Smarty. All I could see was the (correct) content of my header.tpl and then some weird var_dump-like output of the Smarty object instead of the content of my index.tpl (the body of the page). And that output was gigantic! Maybe it's even an endless loop - I dont know. My browser was about to crash, so I hit "stop".

Then I started to narrow down the problem. I deleted everything in the outer template except {include file="filename.tpl"} (relative path, both templates are in the same folder). And I deleted everything in the inner template except "hello world". The weird var_dump-output was still there.

Then I began to remove the $smarty->assign()'s in the original .php-file. I was able to remove all assignments that dealt with simple values (strings, numbers, booleans) while keeping the error. So, what was left was 1 assignment of a quite large array of objects. After removing the assignment of this array, the templates were displayed correctly.

Then I restored the deleted code in all files (the php and the 2 templates) - and against all odds, everything was working fine!

Then I deleted the contents of templates_c and everything was back to "normal" (i.e. the error with the var_dump-output came back).


My guess
Therefore my guess is that Smarty is somehow unable to compile the templates when there is a {include} in the template's code. I observed a similar behavior as described above in other templates (that also included other templates). So maybe you could have a look at compiling {include}'s?


As I said, it's really hard to reproduce and I'm far from being able to provide sample code. But maybe I described the problem in sufficient detail, so you can still have a look at the piece code that might be the culprit.

That'd be great! Because the bug somehow puts me in a delicate position (I could revert to 3.0 but then I wouldnt be able to receive any updates of Smarty anymore...)

Best regards


PS: In the meantime I tried the very latest revision from the SVN (rev4354). Without success.


PPS: I just want to stress that it seems to be sufficient to remove the assign() of the big array in order to make the templates work.
In case of an error, the compiled template for the index.tpl is not generated fully. Instead, I find a file called "wrt4e8b6948e7a31" in templates_c.
After removing the assign of the array, the template is compiled correctly (now named "...some characters....file.index.tpl.php").

The content of the two generated files is almost the same, except for some random-character-strings in the head of the files (e.g. in "'unifunc' => 'content_4e8b6948e5aeb'").

In case it helps I uploaded a zip containing both compiled files (the correct and the broken one): http://www57.zippyshare.com/v/79871858/file.html I have sent the PW for the zip to u.tews via PM - I hope that's ok

[Mastershrimp]

Good morning

still working on narrowing down the problem. Now I think {include} is not important. At least I was able to reproduce the error with just 1 template containing "bla". So it's not about the template.

So, basically the browser crashes because somehow the Smarty object is var_dump'ed while compiling the template. And since the Smarty object has got that huge array, the var_dump takes forever (or is actually endless). The array is huge because it contains objects that have properties that contain objects themselves that contain....and so on, you know There are actually also some recursions within that structure (var_dump prints "RECURSION"), so it's really big and definitely not var_dump'able

I am really wondering why the Smarty object is printed at all. Did you change something like that in 3.1.x? 3.0 was fine, as I said.

Maybe something with the output buffer (ob_start/ob_get)?
Or some left developer debug output?

The weird thing is, that locally it works perfectly. Btw, the server is running Apache/2.2.3 (Debian) PHP/5.2.8-0.dotdeb.1 with Suhosin-Patch. I'm not sure, but I vaguely remember some problems with the Suhosin patch (with some other scripts). So maybe there is a problem with Smarty and that patch? Do you have such an environment that you could use for testing purposes?

[Mastershrimp]

Sorry for posting again, just wanna keep you up2date

I significantly reduced the number of objects in the array (by deleting contents in the DB). Now I get
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 103574794 bytes) in /var/...my path.../inc/globalFunctions.inc.php on line 31

That line is one of my own escape methods

[rodneyrehm]

just a hunch: please check your ->assign() calls and make sure their return values are not processed in any way. For a quicker test, comment out all "return $this;" in Smarty_Internal_Templatebase.php
_________________
Twitter

[Mastershrimp]

Thanks!

But I'm not aware of using the return value of $smarty->assign()....didnt even know that it would make sense at some point. I quickly checked my code with a regex and it seems I'm using it only like "$smarty->assign(...)".

However I'd still like to do your quick test. However I couldnt find any "return $this;" in smarty_internal_templatebase.php. Only stuff like "return $this->$property_name;" and so on.

Could you give me a line number so I can see what you mean?

In case that doesnt help, do you have another idea? I'm willing to try basically anything - I really need this fixed, you know

[Mastershrimp]

Not sure if it helps, but I actually dont use Smarty directly but rather as an extended sub-class "MySmarty". Maybe I'm using it the wrong way?

This is the constructor of the class:

[U.Tews]

Globe

[rodneyrehm]

See? I told ya I needed to eat before getting back to Smarty!
_________________
Twitter

[Mastershrimp]

Haha, no hurry

But I'm sorry, the error remains. I cleared templates_c.

[rodneyrehm]

have you removed "return $this;" from Smarty_Internal_Data.php?
_________________
Twitter

[Mastershrimp]

Yes, sure. Commented all "return $this"'s out. Then cleared templates_c and hit reload. Same thing.

Edit: Also removed the "return (string) $this" from Smarty_Variable::__toString().

[Mastershrimp]

So, do you have any idea how to fix it? So far the only option I have is downgrading Smarty to 3.0x....but that cannot be it I guess :/

[rodneyrehm]

can you identify where that memory limit exceeded error is happening? (Stack trace or something?)
_________________
Twitter

[Mastershrimp]

Yeah, kinda at least. During my experiments with different templates I saw that the memory limit exceeded in one of my output functions. I use them all the time to mask HTML and so on. I also registered them as modifier. But as I said earlier, I reproduced the error just with a template containing "hello world" (no code, no modifiers, no nothing). So it's not about the template I guess. Rather sth with the compiling or so....no idea.

The affected function was:

[rodneyrehm]

well, I'm pretty sure this is not a compiler-problem. This has got to do with the data you've assign()ed. did you throw the $smarty object into the assign()ed array?
_________________
Twitter