如何在apache2+php5.6环境（含WordPress）触发段错误用于核心转储排查？

Been there, done that—debugging segfaults in Apache2 + PHP 5.6 (especially with WordPress) can feel like hunting a ghost at first, but once you get coredumps working and know how to reliably trigger the crash, you’re well on your way to fixing it. Let me share the exact workflows I’ve used in staging and even production (carefully!) over the years.

By default, most systems restrict coredump generation—we need to lift those limits first.

• Adjust system-wide core dump limits
  Edit /etc/security/limits.conf to make the change permanent for the Apache user (www-data):

  www-data soft core unlimited
  www-data hard core unlimited
  

  For a temporary test (resets on reboot), run ulimit -c unlimited as root before starting Apache.

• Configure Apache to allow coredumps
  Edit your Apache environment config (usually /etc/apache2/envvars) and add:

  export CORE_DUMP_DIR=/var/coredumps
  ulimit -c unlimited
  

  Create the dump directory and set proper permissions:

  mkdir -p /var/coredumps
  chown www-data:www-data /var/coredumps
  chmod 770 /var/coredumps
  

• Systemd-specific fix (if applicable)
  If your server uses systemd, you’ll need to override Apache’s service limits too. Create /etc/systemd/system/apache2.service.d/override.conf:

  [Service]
  LimitCORE=infinity
  

  Then reload systemd and restart Apache:

  systemctl daemon-reload
  service apache2 restart
  

We’ll cover two scenarios: testing your coredump setup with a forced crash, and reproducing real-world WordPress-related segfaults.

Test Coredump Setup with a Forced Crash #

This is the quickest way to verify your config works. Create a simple PHP script in your WordPress directory (e.g., wp-content/test-segfault.php):

<?php
// Send a segmentation fault signal to the current PHP process
posix_kill(getmypid(), 11);
?>

Visit this script in your browser. If everything’s configured correctly, you’ll get a 500 error, and a core.XXXXXX file will appear in /var/coredumps.

Reproduce Real-World WordPress Segfaults #

If you’re chasing an intermittent crash tied to WordPress, try these tactics:

• Target high-traffic or problematic pages: Use tools like ab (Apache Bench) to stress-test the page that triggers crashes:

  ab -n 100 -c 10 http://your-site.com/your-problem-page/
  

  Segfaults tied to memory leaks or race conditions often surface under load.
• Test plugin/theme conflicts: Disable all plugins and switch to a default theme (like Twenty Seventeen), then re-enable them one by one. Many PHP 5.6 segfaults come from outdated plugins that don’t handle memory properly.
• Mess with OPcache: PHP 5.6’s OPcache has known segfault bugs in older versions. Try disabling it (opcache.enable=0 in php.ini) to see if the crash stops—if it does, you’re likely hitting an OPcache-specific issue.
• Trigger edge-case PHP functions: Some older PHP 5.6 functions (like mb_convert_encoding with malformed long strings, or certain image processing functions in GD) can trigger segfaults. If your WordPress site uses these functions heavily, craft a test request to push them to their limits.

Once you have a core file, use gdb to dig into what caused the crash.

• Install debugging symbols: You’ll need debug packages for Apache and PHP 5.6. On Debian/Ubuntu-based systems:

  apt-get install apache2-dbg php5.6-dbg
  

• Launch GDB with the core file:

  gdb /usr/sbin/apache2 /var/coredumps/core.XXXXXX
  

• Get the crash call stack: Run bt full in the GDB prompt to see exactly where the crash happened:

  (gdb) bt full
  

  This will show you if the crash originated in PHP’s core code, a third-party extension, or (less likely) a misbehaving WordPress plugin calling into broken C code.
• Dig deeper: Use commands like info sharedlibrary to list loaded extensions, or print to inspect variable values at the crash point.

• PHP 5.6 is end-of-life, so many segfaults are known bugs. Check PHP’s historical bug database for existing fixes or workarounds.
• Never test this on a production site without a backup—segfaults crash Apache processes, which can take your site down temporarily.
• If coredumps aren’t generating, check /var/log/syslog for system-level error messages (common issues include SELinux restrictions or disk space limits).

内容的提问来源于stack exchange，提问作者Yannick Dixken