Serendipity Forums

I ran into some odd behavior that I wanted to capture in case it helps someone in the future (maybe even me, if I forget)...

I took a snapshot of my S9Y 1.3.1 instance (running the popfetcher plugin, configured as "internal") and set it up in dev to test moving to S9Y 1.5.1. As expected, and after some various reconfiguration to account for differences in paths, etc, everything in the dev environment worked just fine - though I didn't test popfetcher because I don't have a dev mail server setup...as such, it's configuration wasn't changed.

Other things that were done in the dev environment include upgrading to PHP 5.2.11 from 5.2.3, installing the latest zenPHOTO in a sub-directory off of the S9Y install, and switching between the Xinha and TinyMCE plugins in S9Y to see if I'll go with Xinha once I move to 1.5.1 in prod.

I also had to mess around with the Categories plugin to get some customizations back into place after the s9Y upgrade.

At some point, and I don't exactly remember what immediately preceded it, S9Y began throwing up blank pages no matter what I attempted to hit - admin, index, etc., though non-S9Y php would still render, such as my phpinfo() page in the S9Y install directory.

To isolate the problem, I ran a fresh S9Y 1.5.1 install against an empty database, determined it worked. Through a process of elimination, I ultimately determined that the problem was in the table serendipity_plugins, and that it was something to do with the popfetcher entry. Once this row was deleted, everything began functioning as it should.

Oddly, there were no http errors or php errors, though there might be mysql errors (my log reader isn't cooperating), and I was getting http:200 responses in the connection log. The first suspects were .htaccess, something weird in the S9Y filesystem, and something to do with the spamblock plugin, but this was quickly eliminated.

I still don't know what the problem was - I can easily duplicate it by moving the original _plugins table back. I'm pretty sure this is a very unique situation, but if it turns out to be somehow 1.5.1-related, or warrants further investigation, I've got data to share. The popfetcher plugin has been reinstalled, but not configured, and everything continues to work just fine.

Adam

Hi!

Hm, this actually sounds a lot like possible PHP Fatal Errors. How did you configure your php.ini "display_errors" directive? Do you run PHP as CGI or mod_php? Those two yield different error logs (CGI goes into a general CGI logfile, independently of what PHP is instructing).

So I think it could be ressource allocation problems in the popfetcher plugin, maybe it wanting to connect ot a POP server failed. Though, when you configure it as "internal" it shouldn't be executed at all, only loaded.

However when you have many plugins, you could have used up all the RAM...in that case, a HTTP 200 header could still be sent.

I'd really like to resolve this situation, if you are currently able to reproduce it!

Best regards,
Garvin

Hi Garvin,
I'll be happy to provide whatever you want to take a look at - to me, the problem kind of begs of corruption in the popfetcher row in the _plugins table, but can't think of how that would happen. I was fiddling around with plugins quite a lot - disabling/enabling the tinymce plugin, messing with the category plugin, etc.

To cover your questions, I'm running php in CGI mode,
display_errors=on
display_startup_errors=on
log_errors=on
report_memleaks=on
error_reportings=e_all & ~e_notice

A couple of PHP errors to report:
[Tue Oct 06 15:13:12 2009] [error] [client 127.0.0.1] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 792 bytes) in C:\\Servers\\Apache\\htdocs\\pigslipstick\\plugins\\serendipity_event_spartacus\\serendipity_event_spartacus.php on line 293\n
[Tue Oct 06 15:14:43 2009] [error] [client 127.0.0.1] PHP Fatal error: Cannot redeclare class serendipity_event_tinymce in C:\\Servers\\Apache\\htdocs\\pigslipstick\\plugins\\serendipity_event_tinymce\\serendipity_event_tinymce-orig.php on line 278\n

I bumped up the available memory from 8mb to 10mb in response to error 1, and error 2 gets thrown until I uninstall the tinymce plugin when I'm doing plugin management (then I reinstall it). I modified tinymce to handle block quotes better a long time ago.

I can provide the popfetcher row out of _plugins if you'd like - I'd rather email it since I assume it contains login info in the hash...just let me know.

Just for reference, yes, the popfetcher plugin is (or was) configured for internal for my production server, and I may have executed it accidentally in dev so it would have failed. It should never have tried to auto-execute given the configuration.

My dev machine has 2gb of RAM and didn't go unresponsive as though there was no memory available, though PHP may have reached it's 8mb limit I suppose, but would have expected to see some errors reported. Also, I restarted Apache a number of times which should have cleared any memory related things.

Thanks,
Adam

Hi!

The data inside _plugins DB table does not contain any sensitive information; so if you could give a SQL dump of that single row, it would help. It might be that the path information etc. might be wrong.

Your PHP memory limit is configured at 8MB of ram. You might want to check php.ini and set memory_limit = 32M or somethin glike that, as 8M is really very little.

HTH,
Garvin

Thanks Garvin, yes, even at 10mb, S9Y throws errors when I search plugins - I really should just bump it up to 32mb (like production).

If this makes it easier, here is the popfetcher row out of _plugins ready to import:
INSERT INTO `serendipity_plugins` (`name`, `placement`, `sort_order`, `authorid`, `path`) VALUES
('serendipity_event_popfetcher:cb4ee226f94d0a6cea02cc739721871a', 'event', 16, 0, 'serendipity_event_popfetcher');

Definitely the paths and stuff are all wrong - this was a migration from a *NIX production server to my Wintel dev server...so if (accidentally) executing popfetcher with bogus paths defined would lead to all of S9Y yielding content-less "white" pages throughout, then we have our answer. Let's see what happens if I execute it right now.
- Installed the plugin in dev.
- Executed once without configuring anything to see what happens...just get the "no mail server configured" error.
- Configured just like production.
- Executed, and it's checking the production mailbox and behaving as-expected.
- Installed TinyMCE, re-ran popfetcher, everything is cool.
- Messed with the order of the plugins, re-ran popfetcher, still everything is cool.

These are the things I know I did leading up to whatever happened with the popfetcher row in _plugins. The more I mess with this (and try to duplicate it) the more I think this is just some strange environmental issue - maybe the database restore, or some odd PHP memory thing when messing with plugins.

Garvin, unless you're just dying to mess around with this, I think we should just let it go and move onto more interesting things - for instance, I just upgraded S9Y in production to 1.5.1b1 and want to try out the Xinha editor

Hi!

The plugins table seems usuall. I bet, it's just a ressource/memory problem somehow, because then what changes WITH this DB table line is that the serendipity_event_popfetcher.php file gets included. Just for test, you could change the "path" column of that line to an empty string instead of "serendipity_event_popfetcher"?

Anyhow, I guess it has resolved itself now, maybe it simply was a flakey environment. So if you don't face the error any more, let's just move on

Regards,
Garvin