I recently upgraded zenphoto to 1.5.7, I had upgraded it several times previously without issue however this time I've encountered an issue where a php query is apparently chewing up a ton of memory resulting in the page not being rendered. The following is the error I'm receiving when trying to view any webpage through my existing zenphoto install:

[code]
[Wed Sep 23 17:33:57.534200 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/zenphoto/zp-core/functions-db-MySQLi.php on line 134
[Wed Sep 23 17:33:57.534272 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP Stack trace:
[Wed Sep 23 17:33:57.534292 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 1. {main}() /var/www/html/zenphoto/index.php:0
[Wed Sep 23 17:33:57.534307 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 2. include() /var/www/html/zenphoto/index.php:56
[Wed Sep 23 17:33:57.534322 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 3. require_once() /var/www/html/zenphoto/zp-core/index.php:14
[Wed Sep 23 17:33:57.534336 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 4. require_once() /var/www/html/zenphoto/zp-core/functions.php:18
[Wed Sep 23 17:33:57.534350 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 5. getOption() /var/www/html/zenphoto/zp-core/functions-basic.php:215
[Wed Sep 23 17:33:57.534365 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 6. query_full_array() /var/www/html/zenphoto/zp-core/functions-basic.php:353
[Wed Sep 23 17:33:57.534380 2020] [php7:notice] [pid 29427] [client 176.113.115.214:37338] PHP 7. mysqli_result->fetch_assoc() /var/www/html/zenphoto/zp-core/functions-db-MySQLi.php:134

[/code]

When I initially encountered the issue I was still running php 5.x so I upgraded to 7. PHP's memory limit was also initially 128M and I bumped it to 256M (which seems like a lot when 128M previously worked fine) - ultimately I ended up bumping the memory up to 1G and things started working - but again this seems excessive when 128M previously worked.

Has anyone else encountered a similar issue? was there a resolution other than "feed it gobs of memory until it works"?

I also created a new install of zenphoto from scratch and ran through the setup. This seemed to work just fine. I kind of suspect the issue came about somewhere along my upgrade path and I'm not entirely sure where to go looking.

The issues seems to be related to the options which are indeed generally prefetched in total once and cached internally on runtime. I will review that principle now that you pointed me to it. Possibly we should change that to indeed load only a requested option - even if that means a lot more small db queries, but lot small queries are generally faster than larger ones - and then cache for further usages instead instead of all.

Actually setup should cleanup options a little from options of non existing themes and plugins at least. Please take a look at the size of the options table. I don't know why any upgrade would cause that much more memory usage. What version did you upgrade from? If that was at least 1.5.x something I have no idea.

But setup does not/cannot do this for everything savely so there might be a lot unused option entries left. Especially if this is a really old install . Hot fix would be that you could clear the options table manually. You would have to re-set every option (ZP, theme, plugins) again afterwards.

I have had this install of zenphoto for quite some time and have upgraded semi-regularly. I believe I upgraded from 1.5.x this go-around. I have a "large" number of personal images I store here and that's about it. I set it up and it's just worked for a number of years; I don't frig around with extra themes or plugins etc. I modified one stock theme years ago and that's all I've used.

I just had a look at my options table:

[code] Showing rows 0 - 24 (684316 total, Query took 0.0004 seconds.)
[/code]

While there does appear to be a pile of entries, the query certainly didn't take very long..

If you'd like something specific from me please do not hesitate to ask, I'm quite willing to help whoever get to the bottom of this.

I looked up the lines mentioned on your report above and those were related to fetching the options. You apparently have 684316 rows in there so that is a lot and does add to the memory used by other things (for example image processing which needs the most).

It may not have been the options itself but some combination wiht something else. Like lots of images that for some reason have sizes generated. .
That will be hard to find out what exactly it was You could try to disable plugins one by one to find out the culprit for example. If you have a link to the site in question I could at least take an outside look.

Sure thing, head over to http://dewie.ca

Now to add an added bit of complexity for you to try to diagnose anything remotely, it's self hosted; and I only get 1mbit upstream (on a good day) as my ISP is a wireless provider as I live "in the middle of the woods"

Some slowness you see of things loading may be attributed to that; particularly loading full resolution photos.

I have taken a quick look. I cannot see or tell really much but the site does not look that huge or feels that terribly slow (a little delay which seems "normal" given your connection you described). How many images and albums do you have in total?

I see you are using the zpBoostrap theme. You should also upgrade that as you seem to have 1.4.6 and current is already 2.3.2.

Thanks for the heads-up about the theme. There is apparently 12173 Images (more than I thought haha)

Okay, that is a number but we've had users with more. I'd say perhaps for now let's observe if this ever happens again.

If you really have 684316 rows of options, something is really strange. I looked at my test sites. The norm is about 1500 rows. The smallest is just over 1100 rows and the largest is 1850 rows.

I wonder if somehow you have duplicate entries. If so that could cause problems.

My test sites also have between 1300-2300 rows in the options tables, the latter for really old "grown" test installs with lots of plugin/theme tests etc. As suggested a manual cleaning of the whole table and resetting everything will be the best. if it then grows unexpectedly again…

I just had a look through the table; looks like a bunch of depreciated titled stuff, then I ran across this...

Is that Injected code somehow?

Allllll kinds of Page-Hitcounter entries also

And then there is many of these kinds of entries also

I did some quick queries and:

[code]SELECT * FROM zenphoto-zenphoto-1_4_11_options where name = "comment_form_toggle"
[/code]
Showing rows 0 - 24 (232145 total, Query took 0.0066 seconds.)

[code]SELECT * FROM zenphoto-zenphoto-1_4_11_options WHERE name LIKE "%Page-Hitcounter%"
[/code]
Showing rows 0 - 24 (26453 total, Query took 0.0018 seconds.)

The page-hitcounter are the hitcounter plugin. They look indeed like db injection attempts.

I doubt that these caused any actual harm actually except causing garbage data as data is escaped when added to the database.

To get rid of the hitcounter ones you could the button "reset all hitcounters". That will reset those on all real pages and delete all the others. If you don't need it you can then just disable the hitcounter plugin.

There is currently only a validation for "known" pages like images, albums or Zenpage items. But for so called static custom pages that any theme can define as it likes there is no such validation. These are not exactly "known". I will look into to add some option so only existing static pages of the current theme can be selected for hitcounts or something.

The comment_form_toggle/pagination are valid options of the comment_form plugin. Those look like duplicates I have no idea about. May be from years ago when things went wrong. Or the slowconnection on your site at times you mentioned has or had unexpected side effects…

I cannot exactly reproduce the injection so far. Hitcounter seems to not log pages that don't exists and thrown an 404 error. Which of course also happens for non existing static pages (there is actually no validation needed therefore). 404 pages are not counted.

I hit the "reset all hitcounters" button and it certainly deleted some entries:

Showing rows 0 - 24 (718812 total, Query took 0.0005 seconds.)
Showing rows 0 - 24 (684712 total, Query took 0.0004 seconds.)

I then looked at the plugins page and confirmed that the comment_form plugin is disabled... is it possible someone is injecting comments somehow still? Where I use the site for primarily personal use I really don't care if I have comments or not and as such I'm sure I disabled the functionality when I first set the site up.

It should not be possible. But any kind of bug can never be exclude. I can only say I never ran into this on any site including our own which also does not use comments.

I think best you investigate this over the next time. Let me know if it re-appears. I don't remmeber what your previous version was but there certainly have been some security related fixes if it was older in case these are just leftovers from years ago or something.

Ok, It's very possible the problem has already been corrected; just very strange the problem I experienced only presented itself with this new version.

Thank-you very much for your assistance!

Just to follow-up, I deleted a bunch of garbage entries:

[code]DELETE FROM zenphoto-zenphoto-1_4_11_options WHERE name LIKE "%comment_form%"
[/code]
474518 rows affected.

[code]DELETE FROM zenphoto-zenphoto-1_4_11_options WHERE name LIKE "%tinymce4_comments%"
[/code]
237253 rows affected.

and I now only have 499 rows in the options table mile:

I then reverted the maximum memory available for php back to 128M and immediately I am getting a memory error again

[code]
[Sun Sep 27 08:33:12.971370 2020] [php7:notice] [pid 19231] [client 216.244.66.228:46648] PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 65536 bytes) in /var/www/html/zenphoto/zp-core/index.php on line 14
[Sun Sep 27 08:33:12.971407 2020] [php7:notice] [pid 19231] [client 216.244.66.228:46648] PHP Stack trace:
[Sun Sep 27 08:33:12.971421 2020] [php7:notice] [pid 19231] [client 216.244.66.228:46648] PHP 1. {main}() /var/www/html/zenphoto/index.php:0
[Sun Sep 27 08:33:12.971433 2020] [php7:notice] [pid 19231] [client 216.244.66.228:46648] PHP 2. include() /var/www/html/zenphoto/index.php:56
[/code]

499 rows sounds really good

But this is really weird… The line /var/www/html/zenphoto/zp-core/index.php on line 14 in question is from the inlcude of the general function.php file within the core index.php file. That now can be everything as there is of course a lot of things going on…

Btw, we have 128mb memory on our own site as well and it is not even that specific hosting actually. And the site runs since I think 1.2.8 when we made it. There was no actual db cleanup option wise although we did migrate to another server at one point.

That's not an overly useful stacktrace then...

My website is just for personal use, as you can likely tell by how infrequently I reply I don't have a whole lot of time for it at the moment. I will try to investigate later.