3

I'm looking for a relatively painless way to track down segmentation faults in PHP (as reported in the Apache error log). This is my LAMP setup at the moment:

Linux: OpenSUSE 11.3 x86_64
Apache: 2.2.15-3.7
MySQL: 5.1.46-2.18
PHP: 5.3.2-1.31

The code in question is not my own, it is Gallery2: http://gallery.menalto.com A typical scenario is that I go to the gallery main page and none of the thumbnails appear but I get a new set of segmentation fault errors in the error log.

Given the relative complexity of that software, it's not particularly suited to simple forms of debugging. I'd like to be able to step through the code and see exactly what is happening. "Solutions" I've seen so far for doing this have been pretty far from "relatively painless."

I've successfully used Gallery2 on this server (earlier versions of LAMP software packages) and on other servers, so I assume there is something defective in my current configuration, but without being able to see where the fault is occurring, I can't fix or work around it.

|improve this question
  • Question much better suited for serverfault.com . I will say Gallery in latest forms seems to be fairly resource intensive. Generally if there is a mechanism to allow it to do caching of SQL queries (latest versions require MySQL) then you're going to have better luck. – artlung Jul 26 '10 at 22:21
  • As a Web programming question, it doesn't seem to fit the FAQ for serverfault.com...? – S. W. Jul 27 '10 at 0:31
  • 2
    S.W.: Seems like a problem doubly suited to stackoverflow and serverfault, because the source of the problem is unknown, and could be server configuration related. In cases like this, I argue some place should embrace the question and take a shot. I hate it when people have frustrating questions that can't find a home because each site argues it's "not part of what we do!" It's like getting the runaround from a government agency. Someone step up and help! – artlung Jul 27 '10 at 6:04
2

May I suggest looking at http://sourceforge.net/tracker/index.php?func=detail&aid=1692166&group_id=7130&atid=107130 and http://gallery.menalto.com/node/62436#comment-228570?

There seem to be common problems with either using apache_setenv or gzipping the URL twice (depending on the scenario - the former seems more likely with the thumbnails not appearing):

I believe that the problem is that mod_deflate tries to gzip the data a second time based on the URL, which results in breakages on some systems. Telling it not to gzip the files that we're sending helps out in this case.

There may be a bug in PHP. Try adding $gallery->setConfig('apacheSetenvBroken', 1); to your config.php to disable using the apache_setenv() function

Appreciate this is not the answer to the question you are asking (beyond using Zend Framework with plugins or command line php and gdb I do not know how to debug segfaults in PHP) but it may help.

|improve this answer
  • I appreciate the input. I did experiment a bit with that but didn't make any progress. Then I recalled reading a suggestion to switch the config.php for Gallery2 to use just mysql or mysqlt instead of mysqli. I changed it to mysqlt and things (at the moment) seem to be working. Would still be interested in debugging options though, for the future and also in case this isn't the solution to my current problem. – S. W. Jul 26 '10 at 20:43
  • Question would be does this only happen in PHP 5.3.2 (and not 5.3.0)? If so then chances are that the bug lies in Zend and only cli php with GDP will show you the problems. There are known bugs in the 5.3.x series regarding segfaults. – Metalshark Jul 27 '10 at 6:37
  • A quick search like this google.co.uk/… will reveal many - however from our tests there was a big change between 5.3.0 and 5.3.2 where it will segfault in one version and not the other (and visa-versa). – Metalshark Jul 27 '10 at 7:26
0

To debug PHP segfaults you'll normally make a new .php file (so that it does not interfere with your main code) like so (calling it my_first_debugger.php):

<?php
include('annoying_caller_page_that_crashes.php');
?>

Then run gdb php. If gdb is not installed or the gdb/php binaries are not in your path there will be errors so use YaST2 to install everything required (get the development/debug libraries for php too as they usually include debugging symbols).

You'll get output like:

GNU gdb x.x
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
(gdb)

Then just do a run my_first_debugger.php in the command line.

Look for -dev and -dbg packages if there are messages like (no debugging symbols found) or you may not see the name of the function being called.

|improve this answer
  • From a Webmaster stand point though it may be worth considering having a known-good version compatibility chart and maintaining it. Making compromises and thoroughly understanding the interconnected nuts and bolts (and how they crash together) is all part of the fun. When it gets to the point you have to include debugging symbols on a Webserver the words "seek alternatives" are normally suspended overhead in vibrant neon. – Metalshark Jul 27 '10 at 7:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.