Check system and application logs using journalctl, application-specific log files, and desktop environment logs to identify error messages; 2. Use dmesg to detect kernel-level issues like OOM killer actions or segmentation faults; 3. Run the app from the terminal to capture real-time error output such as missing libraries or permission issues; 4. Verify dependencies with ldd and resolve missing or conflicting shared libraries; 5. Test with a clean user environment by creating a new user or renaming config directories to rule out corrupted settings; 6. Use gdb for crash backtraces and strace to monitor system calls for failures; 7. Check resource limits including memory, file descriptors, and GPU driver issues, and try software rendering if needed; 8. For sandboxed apps (Flatpak, Snap, AppImage), verify permissions and execution requirements; always update the system and search for known bugs using error messages, as most crashes stem from missing dependencies, configuration problems, resource constraints, or application bugs, and using these steps systematically will help identify and resolve the root cause effectively.

Application crashes on Linux can be frustrating, especially when they happen intermittently or without clear error messages. However, Linux provides powerful tools and logs to help diagnose and resolve these issues. Here’s a practical guide to troubleshooting application crashes effectively.

1. Check System and Application Logs

The first step is to look for error messages in system and application logs. These often contain clues about what went wrong.

• System logs via journalctl (for systemd-based systems):

  

  journalctl -xe

  Or filter by a specific service or time:

  journalctl -u your-service-name.service
  journalctl --since "2 hours ago"

• Application-specific logs:
  Some apps write logs to /var/log/ or their own directories (e.g., ~/.appname/logs/). Check the app’s documentation for log locations.

  

• Xorg/Wayland and desktop environment logs:
  GUI app crashes might relate to display servers. Check:

  • ~/.xsession-errors (older X11 sessions)
  • journalctl -b for desktop-related errors
  • Wayland compositor logs (e.g., gnome-shell via journalctl)

2. Use dmesg to Catch Kernel-Level Crashes

When an app crashes due to a segmentation fault or memory violation, the kernel logs it. Use dmesg to see if the process was terminated by the OOM killer or crashed with a signal.

dmesg | grep -i "killed process"
dmesg | grep -i segfault

Example output:

[12345.67890] Out of memory: Kill process 1234 (firefox) score 500...
[12346.12345] traps: app_name[5678] general protection fault...

This tells you whether the app was killed due to memory pressure or had a low-level crash.

3. Run the App from the Terminal

Always try launching the app from a terminal emulator. Even GUI apps often output useful debugging info when run from the command line.

your-app-name

Look for:

• Python tracebacks
• Missing libraries (error while loading shared libraries)
• Permission denied errors
• GTK/Qt warnings that hint at configuration issues

Example:

$ gimp
gimp: error while loading shared libraries: libgegl-0.4.so.0: cannot open shared object file: No such file or directory

→ This means a library is missing; install it via your package manager.

4. Check Dependencies and Libraries

Use ldd to verify that all required shared libraries are present:

ldd /usr/bin/your-app

Look for any line saying "not found". If so, install the corresponding package using your distro’s package manager.

Also, watch for mixing libraries from different sources (e.g., mixing Flatpak, AppImage, and native packages), which can cause conflicts.

5. Test with a Clean User Environment

Sometimes configuration files (in ~/.config/, ~/.local/, or ~/.appname/) become corrupted.

To test:

• Create a new user:

  sudo adduser testuser
  su - testuser
  your-app-name

• Or temporarily rename config directories:

  mv ~/.config/appname ~/.config/appname.bak

If the app works, the issue is likely in your user config.

6. Use Debugging Tools: gdb and strace

For deeper analysis:

• gdb (GNU Debugger): Catch crashes in real time.

  gdb your-app
  (gdb) run

  When it crashes:

  (gdb) bt    # shows backtrace
  (gdb) info registers

• strace: Trace system calls to see what the app is doing before crashing.

  strace -f your-app 2>&1 | tee trace.log

  Look for repeated failures like open() = -1 ENOENT or kill signals.

7. Check for Resource Limits and Conflicts

• Memory: Use free -h and htop to check if the system is running out of RAM.
• File descriptors: Some apps hit limits. Check with:

  ulimit -n

• GPU drivers: Crashes in graphics-heavy apps (games, browsers, IDEs) may stem from GPU drivers. Try:
  • Updating Mesa or proprietary drivers (NVIDIA/AMD)
  • Running with software rendering:

    LIBGL_ALWAYS_SOFTWARE=1 your-app

8. Consider Sandbox Environments (Flatpak, Snap, AppImage)

Sandboxed apps can fail due to permission issues.

• Flatpak: Check permissions with:

  flatpak list --app
  flatpak permission-list

  Reset if needed:

  flatpak permission-reset com.example.App

• AppImage: Ensure it has execute permission and required FUSE support.

Final Tips

• Keep your system updated: sudo apt upgrade, sudo dnf upgrade, etc.
• Search online using exact error messages — someone else likely had the same issue.
• If it’s a known bug, check the app’s GitHub/GitLab page or your distro’s bug tracker.

Basically, most crashes come down to missing deps, config issues, memory problems, or bugs in the app itself. Using logs and command-line tools makes the root cause much easier to spot. Don’t skip the simple stuff — sometimes it’s just a missing library.

The above is the detailed content of Troubleshooting Application Crashes on Linux. For more information, please follow other related articles on the PHP Chinese website!