Connection reset when requiring template _init.php

[nixsofar]

I have an odd issue with PW 2.7.2 on a Debian 8.4 server, Apache 2.4.10, PHP 5.6.19-0+deb8u1

From a certain point I was getting an empty server response when calling any page (Firefox http: "The connection was reset", https: "Secure Connection Failed" / "The connection to the server was reset while the page was loading.")

I've tracked it down to wire/core/TemplateFile.php, line 180  

require($_filename);

I can exit ok before this line, but an exit() at the next line won't be reached
 

Except for the debug lines, all files in the wire directory tree are left unchanged   

Additionally I've checked all files for syntax errors

$ find . -regex '^.*\.\(php\|module\|inc\)$'|grep -v '\.phpstorm\.meta\.php' | xargs -i php -l {} | grep -v 'No syntax errors'

after having had a similar experience as a result of a typo in config.php

This is the context:

wire/core/TemplateFile.php

154     /**
155      * Render the template -- execute it and return it's output
156      *
157      * @return string The output of the Template File
158      * @throws WireException if template file doesn't exist
159      *
160      */
161     public function ___render() {
162 
163         if(!$this->filename) return '';
164         if(!file_exists($this->filename)) {
165             $error = "Template file does not exist: '$this->filename'";
166             if($this->throwExceptions) throw new WireException($error);
167             $this->error($error);
168             return '';
169         }
170 
171         $this->savedDir = getcwd();
172 
173         chdir(dirname($this->filename));
174         $fuel = array_merge($this->getArray(), self::$globals); // so that script can foreach all vars to see what's there
175 
176         extract($fuel);
177         ob_start();
178         foreach($this->prependFilename as $_filename) {
179                 if($this->halt)break;
180                 die( "regular exit here");                                            ###### DEBUG
181                 require($_filename);                            ####### PROBLEM HERE! ######
182                 die("won't exit here - empty server response instead");               ###### DEBUG
183 
184         }
185         if(!$this->halt) require($this->filename);
186         foreach($this->appendFilename as $_filename) {
187             if($this->halt) break;
188             require($_filename);
189         }
190         $out = "\n" . ob_get_contents() . "\n";
191         ob_end_clean();
192 
193         if($this->savedDir) chdir($this->savedDir);
194 
195         return trim($out);
196     }

Any ideas how to debug this?

[cstevensjr]

Are you sure this is not a Firefox-specific issue?  Do you run into this same issue on any other browsers?

[nixsofar]

Yes, definitely no browser issue.

Chrome: ERR_EMPTY_RESPONSE

Wget:

HTTP request sent, awaiting response... No data received.
Retrying.

[nixsofar]

There are other PW installations running on this server w/o problem. So probably no Apache or PHP version issue either.

[cstevensjr]

Thanks for providing additional information, which helps with the troubleshooting of your issue.

• Are the functional working PW versions the same as on the problem installation?
• Have you tried reloading the /wire folder to that troubled installation?

[netcarver]

Is the prepend file, required by that template, actually in the correct place? Using die("$_filename"); before the require(...); might point you in the right direction.

Hope that helps.

Steve

[nixsofar]

Thanks for replying guys!

@cstevensjr: yes and yes. The problem installation used to work ok as well before I did whatever to break it.

@netcarver: yes, checked in line 179. Permissions and owner are ok, too.

What happens is a segfault in one or several Apache child processes.
 

I did an Apache and Php5 reinstall, but no luck.

[netcarver]

Ouch. This is getting out of my area of experience. There are a couple lines of enquiry I'd look at now...

• diff the virtual host files for a working site vs the one that segfaults and look for any potential differences
• diff a working .htaccess vs the segfaulting site
• Start looking at how to debug a segfault in apache.

Sorry, I can't be of more help - but please post what you do and what you find out.

Good hunting!

Steve

[nixsofar]

Thanks Steve!

Among others I've done exactly these diff jobs but they gave no clue.

New pw installs do work, so I guess next I'll rebuild the site step by step and watch what's happening.

[nixsofar]

Edit This was the second time I had a hard time debugging a mysterious "processwire error". My lesson:

I will keep in mind that there are circumstances when neither pw, php nor the server software can give me appropriate error messages or log entries.

So first thing if firefox tells me 'Unable to complete this request due to an error' next time will be checking config.php for syntax errors

$ php -l site/config.php

and if I get an empty server response because of an apache segfault like "The connection was reset" (http) or "Secure Connection Failed" (https) I'll very carefully check all my own code in site/templates. If necessary, by disabling and re-enabling script by script.

 

--

Found my stupid error. It was in this little function in _func.php that should retrieve the second level parent of a page:

function getsubpar($page){
    $parid = $page->parent->id;
    ## if($parid == 1){  ##### WRONG! CAUSES APACHE SEGFAULT
    if($parid <= 1){
        return $page;
    }else  {
        $subpar = getsubpar($page->parent);
        return $subpar;
    }
}

With parent id 0 it would recurse forever. Can't expect error messages from a crashed Apache module. Still strange the crash happened exactly at this line in TemplateFile.php

There might be a better way to get these subparents, but pw is working again, problem solved.

Thanks to all!

[netcarver]

@nixsofar,

Really glad you got that tracked down; congratulations. Could you share with us any tips about how you went about finding this? Did you notice a huge number of stack frames in some tool or other? Or was it from single-stepping using Xdebug? Something else entirely?

Always interested in the critical thinking skills and tooling that can help track down bugs.

Thanks!

Steve

[nixsofar]

@Steve Too much honour, sorry, no secret super-tool in my belt... Just vim, ctags, find, grep, <?php die($info) ?> , frequently with __FILE__, __FUNCTION__, __LINE__ information etc

Thanks again for your time everybody!