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.
