I have a page that is heavy in PHP and mySQL that keeps turning up this error in the logs:

[notice] child pid 31467 exit signal Segmentation fault (11)

If I continue to refresh the page, eventually it will complete. Sometimes it will work fine for a while and then on a refresh will stop working. Each time it crashes it does so on the same part of the page. I'm stumped as to what could be the problem, it is only happening on this one page... I have been searching the web for clues but haven't found anything helpful. Anyone have any ideas?

Well, this is no PHP or MySQL issue, it's something to do with the server.
So I did some searching, and here is some info:
http://lists.debian.org/debian-apach.../msg00005.html

I'd contact your host about this problem, it's a problem with their server.

I did see that post in my search, the only thing is that it is occurring exclusively with this particular page when we have a huge site running 90% PHP. Granted, that doesn't rule out that it's a hardware issue, but it is still odd to me that it only gives this error on this one script and at the same place every time.

Never automatically assume (like the author of that post Jasong directed you to) that errors are caused by hardware. Software can cause Hardware to play up if it is not written correctly.

With this fault being consistant to this page only, I would definately go with the code being at fault. The only problem is I cannot say what the problem could be unless you post the code.

Hardware can be stressed by open loops, etc. You stated that it usually crashes at the same point, which points to that, so look for any unintended loops or open queries at this point.

Steve.

Originally Posted by Gaffer Sports

Never automatically assume (like the author of that post Jasong directed you to) that errors are caused by hardware. Software can cause Hardware to play up if it is not written correctly.

With this fault being consistant to this page only, I would definately go with the code being at fault. The only problem is I cannot say what the problem could be unless you post the code.

Hardware can be stressed by open loops, etc. You stated that it usually crashes at the same point, which points to that, so look for any unintended loops or open queries at this point.

Steve.

There's really too much code to post, the page itself is pretty big and it has several include files... it's an osCommerce page that I have added some custom stuff to.

I'm more familiar with traditional C++ programming, I know that if you access bad memory that it may not crash the program for several instructions, does PHP behave in the same way? In other words, should I limit my troubleshooting to the part of the code where it actually crashes or could is just as easily be the first line of code in the script?

php tends to act like C++ in that way. It reads the instructions before executing them, so if it is reading an instruction and an error is noticed it should report it before parsing any data.

It is always good to check the code where you think it is failing, and more often than not it will be a function of some sort. Try tracing the function through from start to finish and see if something vital has been left out by accident.

Is this bad PHP code?

$series_date = date("M Y", strtotime($series_date));

I changed it so that it is not refrencing itself and I haven't been able to get it to crash since I did that. (Not that it was ever predictable...) I'll keep working with it to see if I can get it to crash again with this change.

The weird thing is that it is happening in a loop where I have 5 rows in an SQL query, and it does the first three rows fine, and when it crashes is crashes in the moiddle of the fourth row. This is the loop:

<?
  while ($i < $lines)
    {
      $series_info = tep_db_fetch_array($result);
      $series_id = $series_info["categories_id"];
      $series_title = $series_info["categories_name"];
      $series_speaker = $series_info["speaker_name"];
      $series_id = $series_info["categories_id"];
      $series_title = $series_info["categories_name"];
      $series_speaker = $series_info["speaker_name"];
      $series_format = "MP3";
      $series_date_long = $series_info["date_added"];
      // Convert $series_date to Mon YEAR                                                                      
      $series_date = date("M Y", strtotime($series_date_long));

      // Print the row                                                                                         
      ?><tr>
           <td width=\"200\"><? echo $series_title ?></td>
           <td width=\"100\"><? echo $series_speaker ?></td>
           <td width=\"100\"><? echo $series_format ?></td>
           <td width=\"100\"><? echo $series_date ?></td>
           </td><td width=\"100\"><? echo '<a href="' . tep_href_link(FILENAME_DEFAULT, 'cPath=' . $series_id \
. '&sort=' . PRODUCT_LIST_MODEL . 'd') . '">more info</a></td>'; ?>
      </tr>
<?

      // Increment $i                                                                                          
      $i++;
    }
?>

[tep_db_fetch_array() is just a function that calls mysql_fetch_array() in a series of db functions with osCommerce]

When it crashes it is immediately after the echo $series_speaker on the fourth of five lines.

Well, it crashed again finally, so that didn't fix it...

I've had a similar problem for a few months now. Never found out what it is - hardware has been swapped out but still there. It's definitely a code problem for me. The problem is that it's so intermittent and it's difficult to pin point the exact script or part of script which causes it.

When the segfault happens the server will run fine except for javascript pop up windows. Anything which requires a pop up will just produce a page saying server does not exist type of thing. This will stay like this until Apache is restarted.

Anyway, to get around this I run a cron job to detect if a seg fault has recently happened. If it has then apache is restarted and the problem goes away for a few days.

The beauty with this is that it's fully automatic. Whilst it does not fix the fault it does help 'out of hours'. Here's the script if you are interested:

--------------------------------

#### check_seg_fault
# Check Logfile for segmentation fault. If detected
# stop apache, remove entries from log, restart apache
#

cp /var/log/apache2/error_log /tmp/temp_log
grep -i segmentation /tmp/temp_log >/tmp/segmentation
if test -s /tmp/segmentation
then
/etc/init.d/apache2 stop
grep -v -i segmentation /tmp/temp_log >/var/log/apache2/error_log
/etc/init.d/apache2 start
cat /tmp/segmentation | mutt -s "Segmentation Fault Detected" admin@mysite.com
fi
rm /tmp/segmentation
rm /tmp/temp_log

----------------------------

What this does is to first copy the apache error log to a temp file. The temp file is then grepped to find any seg fault errors. If any were found then apache is stopped, the temp file cleaned of seg faults and copied back to the original error_log. Apache is restarted and a warning email sent to admin.

Bung this in a cronjob to run every few minutes and you don't have to worry about the server running in a reduced state.

As I say though, this is not a solution to the problem. It is just an automated work around whilst the original problem is analysed.

BTW, are you using any graphs or chart packages in your scripts?

Just checking your code. This could be a memory setting thing. Look at your php.ini file, and then your my.cnf. There are options in there for tweaking the memory.

I'd certainly start with the php.ini file and try increasing the memory_limit.

How much ram does the server have? What does top say is free, buffered, cached.