Apache crash report - is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment

Question

I've noticed that my system has been producing this crash report. I'm not sure of why and my knowledge of the inner goings of apache is limited. I'm not really sure what is causing this since nothing in particular has changed on the server. Any help is appreciated. What should I be looking for and examining? What could be the cause of it?

Apport:

ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: called for pid 8384, signal 7, core limit 0
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: executable: /usr/sbin/apache2 (command line "/usr/sbin/apache2 -k start")
ERROR: apport (pid 8618) Mon Jan 25 14:35:24 2016: is_closing_session(): no DBUS_SESSION_BUS_ADDRESS in environment
ERROR: apport (pid 8618) Mon Jan 25 14:35:52 2016: wrote report /var/crash/_usr_sbin_apache2.0.crash

Answer 1

Signal 7 on x86/ARM devices relates to SIGBUS (see: man 7 signal), means Bus error (bad memory access).

A bus error is a fault raised by hardware, notifying an operating system (OS) that a process is trying to access memory that the CPU cannot physically address: an invalid address for the address bus, hence the name. In modern use on most architectures these are much rarer than segmentation faults, which occur primarily due to memory access violations: problems in the logical address or permissions.

See: Debugging SIGBUS on x86 Linux

Could be a bug, faulty Apache module or hardware issue.

Debugging

Since Apport generated crash in /var/crash/, you can check the crash file for more details. You can open it in the text editor, however the core dump file is packed in a base64 format.

To unpack it, run:

cd /var/crash
sudo apport-unpack /var/crash/_usr_sbin_apache2.0.crash _unpacked

See: How can I read a crash file from /var/crash & Debugging Program Crash.

Then run gdb to analyse the crash file:

gdb $(cat _unpacked/ExecutablePath) _unpacked/CoreDump

then type: bt or bt full to check the stack trace.

Assuming your Apache binary wasn't compiled with debugging symbols, it won't be much help. However, you can identify where the crash happened, such as certain Apache/PHP module, for example:

Program terminated with signal X, ...
#0  0x00007f39a616e09a in ?? () from /usr/lib/apache2/modules/libphp5.so

Check also how many frames you've got by scrolling the list from bt command, and if there are too many, like over 1000, the potential problem is with infinite loop somewhere in your code application.

PHP

In case your application is running under PHP, for more advanced debugging with gdb, see: How to get current PHP function name in gdb?

Like in above example, libphp5.so module is the main one dealing with PHP.

To find out which package it belongs to, run:

$ dpkg -S /usr/lib/apache2/modules/libphp5.so
libapache2-mod-php5: /usr/lib/apache2/modules/libphp5.so

Then consider upgrading the faulty library/module.

In case some 3rd party module crashes, consider disabling it via php5dismod, e.g.

$ sudo apachectl -M
Loaded Modules:
...
$ sudo a2dismod somemodule
$ php -m
$ sudo php5dismod somemodule # Optionally.
$ sudo apachectl configtest
Syntax OK
$ sudo service apache2 reload
 * Reloading web server config apache2

Then if the issue is still there, try to reproduce it from the command-line using php. If you can, debug it using an strace, e.g.

$ strace -f php myscript.php
...
gettimeofday({1560725354, 768601}, NULL) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)

Then check the latest actions what PHP process was doing before the crash. To increase size of messages, use -s 1500, to save into log file, use -o file.log.