collapse collapse

* User Info

 
 
Welcome, Guest. Please login or register.
Did you miss your activation email?

* Who's Online

  • Dot Guests: 108
  • Dot Hidden: 0
  • Dot Users: 0

There aren't any users online.

* Shoutbox

Refresh History
  • Shoutbox is not for support!
  • ♦ Ninja ZX-10RR ♦: <3 aegersz
    September 13, 2018, 03:36:09 PM
  • aegersz: I STILL <3 LOVE SimplePortal
    September 13, 2018, 07:11:39 AM
  • aegersz: o LOVE you guys - Simple Portal rocks !
    May 09, 2018, 05:18:59 AM
  • Chen Zhen: our apologies for the site being down.. please read server issues topic
    March 22, 2018, 05:32:38 AM
  • {OCS}MasterSeal: LOL PLEASE forget I just posted that. I found the answer in my own dang post back in 2015. lol sorry!
    July 04, 2017, 10:47:55 PM
  • {OCS}MasterSeal: I know this SB isnt' for support, but I just have a general question. Who would I contact to find out where SP stores its block info? Is it DB driven or files? I searched the site but came up with nothing. probably my fault any insight is appreciated.
    July 04, 2017, 10:43:36 PM
  • ♦ Ninja ZX-10RR ♦: Excuse me but what does Simpleportal have to deal with that?
    February 05, 2017, 08:21:14 PM
  • WhiteEagle: of course IMHO that site appears to be dead :(
    February 04, 2017, 01:08:05 PM
  • WhiteEagle: If I can get that, then I'll use it for that site...
    February 04, 2017, 01:07:35 PM
  • WhiteEagle: decided to not use SMF for any projects, unless I can get a copy of the premium version of the fanfiction archive plugin
    February 04, 2017, 01:06:54 PM
  • expertdecisions: cloudflare
    January 28, 2017, 08:01:47 AM
  • aegersz: SM release 2.0.13 !
    January 12, 2017, 06:00:13 AM
  • raffo: Tks Emanuele, even if I didn't understand the fix :D
    November 07, 2016, 02:01:20 AM
  • emanuele: [link]
    November 01, 2016, 12:43:50 PM
  • emanuele: raffo: the English support board is a good place. ;)
    November 01, 2016, 12:43:38 PM
  • raffo: Where can I find the fix for the shoutbox?
    November 01, 2016, 05:06:09 AM
  • {OCS}MasterSeal: To the SP team, I make a point to come here and thank you as much as possible for your work.  so again, THANK YOU!
    October 28, 2016, 10:38:05 AM
  • emanuele: That's indeed funny, the limit is present only in the patch and not the full install.
    October 22, 2016, 06:14:58 PM
  • phantomm: and from what I see only patch is broken, full install package is fine
    October 21, 2016, 03:44:44 PM
  • phantomm: they say it for over 3 weeks now..
    October 21, 2016, 03:43:52 PM
NEED HELP? If you're looking for support with Simple Portal, look no further than the Support Board!

Author Topic: Potential bug, much weirdness  (Read 30611 times)

0 Members and 1 Guest are viewing this topic.

Offline CoreISP

  • Newbie
  • Posts: 3
  • SMF Version: 2.0.13
  • SP Version: 2.3.6
Potential bug, much weirdness
« on: March 05, 2017, 03:07:20 PM »
Hello everyone!

First of: did you know that following the link in activation email instantly asks you to change your password after activating?
(Guess a leftover of issues you had a while ago.)
To the matter at hand, I'm not sure IF this is a SP bug, an SMF bug or another type of bug; so didn't put it in the Bugs board. If you'd like it there (anyway), I suppose one can move. :)

I was working on debugging a very weird issue together with SleePy earlier today on a forum I have running, and we ran in to some weirdness caused by a Simple Portal block. It is fixed now, but we're not exactly sure how it's fixed. ("It works! I have no idea why!")
But just in case this is a bug: we figured it would be nice to inform you, so you could have a look and potentially fix it; if its indeed an SP bug.

The problem:
Forum displays a white page on index + boards + topics, but no error is generated. Status is 200 OK.
That's a fun way to start your debugging efforts! Not a single error generated anywhere, the white page is apparently "expected". :')
Nothing changed to the server configuration, nothing changed to the forum configuration, nothing changed to the code, no new mods or changes there: absolutely nothing changed. It just simply stopped working out of nowhere.
(Note: other SMF + SP installations on the exact same server had no issues whatsoever.)
Last but not least: the admin pages, including SP admin, still worked fine. Just the boardindex and all vital functions were throwing a white page.


There were some errors in the error_log, but we've had to dismiss them later on:
Code: [Select]
[05-Mar-2017 02:18:18 America/Los_Angeles] PHP Fatal error:  ob_start(): Cannot use output buffering in output buffering display handlers in /home/username/public_html/smf/Sources/Subs.php on line 2865which seems to refer to:
Code: [Select]
                // Was the page title set last minute? Also update the HTML safe one.
                if (!empty($context['page_title']) && empty($context['page_title_html_safe']))
                        $context['page_title_html_safe'] = $smcFunc['htmlspecialchars'](un_htmlspecialchars($context['page_title']));

                // Start up the session URL fixer.
                ob_start('ob_sessrewrite');
This error has some results on the smf community, but nobody ever seems to have figured it out other than thinking the server config to be the likely culprit. (In this case: the server configuration has been eliminated as culprit for 99.9%.) But that error had not been generated anymore for hours, so when doing a differential diagnose: we had to test without keeping that error in mind as well. If an error doesn't generate for such a long time, all caches are gone and you're definitely making requests: it's unlikely to be the problem itself. (Maybe related, but that's another story. :P)

We did some last changes to ob_start in various portions of the code (like the gzhandler) and tested some server configuration changes. No joy, so we can probably rule that error out as current culprit.

After we started disabling pieces of code one by one, it turned out that disabling this section in Subs.php got the forum to load again:
Code: [Select]
// Just so we don't get caught in an endless loop of errors from the footer...
if (!$footer_done)
{
$footer_done = true;
template_footer();
We commented out template_footer();.

Forum loads again, no problem! Ok... that's odd. So let's see why.
We altered the code to:
Code: [Select]
var_dump(array_reverse($context['template_layers']));
echo __LINE__; die;
foreach (array_reverse($context['template_layers']) as $layer)
loadSubTemplate($layer . '_below', true);

Which outputs:
Code: [Select]
array(3) { [0]=> string(6) "portal" [1]=> string(4) "body" [2]=> string(4) "html" } 3553Ok cool, we now figured out the issue is highly likely in Simple Portal somewhere. Blocks? Let's start with them!

In Simple Portal, we disabled a block for Recent Topics. Instant hit. This was the Block causing the issue.
This fixes the issue, no more white page displaying. Everything works again, just Recent Topics are gone.
Enabling it again? Instant white page! Disable any other block? No differences. Only "Recent Topics" causes the problem.

But in comes the voodoo...
We want to keep the forum online, but still have Recent Topics enabled so we can debug pieces of code. So we start setting up Recent Topics permissions to Deny everyone except for admins. We figured that way, only Administrators will get the white page - and regular members can continue using the board. Best way to debug. :) And the admins will just have to deal with it.(tm) 
... But much to my surprise, the forum kept loading after re-enabling Recent Topics again after changing permissions. Even whilst logged in as Administrator. o0

This was rather baffling, so I reverted the permissions back to normal and wanted to start over.
Lo and behold: the forum still works! :-X No white pages displaying anymore, and Recent Topics is showing up to everyone just fine!
Now, we have absolutely no idea how this could happen. We don't know enough about SP's inner workings either. But the very act of changing the permissions, fixed the problem. Of course changing the permissions was probably just random, I bet if we just clicked "Edit block" without changing anything or something simple like a name: it would have worked again as well.
Apparently, editing the block overwrote something somewhere (in the database I imagine?) - and fixed the problem.

To add to the confusion, we pretty much ruled out any caching being the culprit.
- Cache folder empty, but cleared for good measure.
- Server-side cachers forcefully cleared entirely.
- Even killed memcached to ensure that couldn't be doing anything
So all caches cleared: the problem still persisted. Not until we did "Edit block" did everything suddenly get fixed and come back online.
When looking at SP's code, SleePy briefly thought the problem could actually be in SSI.php as opposed to within Simple Portal - but after studying it further, it turns out that could not be the culprit. And resetting permissions on that Block fixing the error pretty much eliminated it even further as potential culprit.

Now of course we're uber interested to hear if anybody knows exactly *how* this can happen, and why Editing the block fixed it. :)
We're a bit amazed at how/why this could've happened, and why "Edit block" instantly fixes it. (What could it have overwritten? And how does it become corrupt?)
We figured maybe it is a bug in Simple Portal somewhere, also since it would appear there've been more (but extremely few) cases in which this just happened without explanation; in which case it would of course be nice to inform you of this so it can perhaps be fixed. :)

Thanks, and if it is indeed a bug: hope this is sufficient information for you to find/fix the problem.
I included as much information as I can recall from memory to describe the issue and show the relevant pieces of code,
but if you need more information: I might have more - just ask and I'll see if I have it. :)
« Last Edit: March 05, 2017, 03:12:15 PM by CoreISP »

Offline emanuele

  • Developer
  • *
  • Posts: 293
Re: Potential bug, much weirdness
« Reply #1 on: March 06, 2017, 10:38:55 AM »
Did you check if the page was entirely without content or maybe the <head> was there?
How did you disable the block the first time? Editing it, or using the green icon in the listing page?

Offline CoreISP

  • Newbie
  • Posts: 3
  • SMF Version: 2.0.13
  • SP Version: 2.3.6
Re: Potential bug, much weirdness
« Reply #2 on: March 06, 2017, 10:53:46 AM »
Did you check if the page was entirely without content or maybe the <head> was there?

I'm afraid that has not been tested by me.
I'll check if SleePy did :)

Quote
How did you disable the block the first time? Editing it, or using the green icon in the listing page?

The green icon in the listing page.

Offline emanuele

  • Developer
  • *
  • Posts: 293
Re: Potential bug, much weirdness
« Reply #3 on: March 06, 2017, 02:37:38 PM »
Weird...
Can't think of any good reason for something like that.
If it was a php error I would expect an entry in some log (usually the apache log I think).
That said, the green icon doesn't really do that much, it just toggles the state value in the database from 1 to 0 and vice versa. It's really just one single query.

In other circumstances, I would ask you "what browser were you using?" and if the answer were Chrome I would dismiss it with the darn persistent cache of the darn thing (from time to time it's rather annoying how difficult is to let it drop a (broken) cached page to pick the new one... :-\).
But with you and SleePy behind I'm pretty sure this was ruled out as well, leaving me with no ideas at all.

Offline CoreISP

  • Newbie
  • Posts: 3
  • SMF Version: 2.0.13
  • SP Version: 2.3.6
Re: Potential bug, much weirdness
« Reply #4 on: March 06, 2017, 03:13:05 PM »
Weird...
Can't think of any good reason for something like that.

I know the feeling :P

Quote
If it was a php error I would expect an entry in some log (usually the apache log I think).

Weird thing is it wasn't an error. :/ It didn't generate an error, so the white screen was pretty much expected behaviour... apparently.
That's why debugging it gave an extra layer of fun, as it means you'll have to start digging to find the surprise, lol.
The HTTP status was "200 OK" as well, usually with something like an internal server error or the likes you'll see the 500's showing up in the logs.
And to top it off: fcgid, which is rather easy to make angry, was happy as well and didn't report any errors, wasn't killing its childs (yeah sorry, that's what it's called :')), and didn't even see any time-outs. Everything was normal, except there was a white page.

That said, the green icon doesn't really do that much, it just toggles the state value in the database from 1 to 0 and vice versa. It's really just one single query.

If it's set to 0, does it execute something less?
If setting it to 0 means the content of that block is not loaded at all, then it would make sense disabling it fixed it. And then whatever it was supposed to execute when on "1" (I'd guess "show the recent posts" :P), was apparently damaged or not what it expected. (And "Edit block" overwrote that.)
That was my best guess, anyway.

Is what that block is supposed to run stored in the database?
That was the best we could come up with: something related to that block got messed up in the database, and "Edit block" overwrote whatever was in there with fresh and proper information - and that caused it to work again. But as I said, we don't know enough about the inner working of SP to tell if that's a stupid theory or one that could make sense. :P

In other circumstances, I would ask you "what browser were you using?" and if the answer were Chrome I would dismiss it with the darn persistent cache of the darn thing (from time to time it's rather annoying how difficult is to let it drop a (broken) cached page to pick the new one... :-\).
But with you and SleePy behind I'm pretty sure this was ruled out as well, leaving me with no ideas at all.

Safari, Edge, Internet Explorer, FireFox, Chrome. =D
« Last Edit: March 06, 2017, 03:16:04 PM by CoreISP »

Offline Chen Zhen

  • The Underdog
  • Operations Manager
  • *
  • Posts: 1326
  • Gender: Male
  • Kinesis
    • WebDev
  • SMF Version: 2.1
  • EhPortal Version: 1.22
Re: Potential bug, much weirdness
« Reply #5 on: March 07, 2017, 12:14:52 PM »

If you were refreshing the apache php log while tripping the white page and nothing was being logged then it must be hitting an exit or a function being suppressed.
It's too bad you weren't able to pinpoint it in one of the files prior to stopping the occurrence via the permission change.