Running application ends with "Segmentation Fault"

Question

I have a command line application that when run does not do what it is supposed to do and at a certain point leaves the message:

Segmentation fault

What does this mean? What should I do?

Solution 1

A segmentation fault is the result of a memory access violation. The program has referred to a memory address outside of what was allocated to it, and the OS kernel responds by killing the program with SIGSEGV.

This is a mistake, since there is no point in trying to access inaccessible memory (it cannot be done). Mistakes of this sort are easy to make, however, particularly in languages such as C and C++ (which account for a lot of common applications). It indicates a bug in either the program itself or a library it links to. If you wish to report the bug (do -- this helps), it is a good idea to include a backtrace of the events that led up to the seg fault.

To do this, you can run the program inside gdb (the GNU debugger), which should be available from any linux distro if it is not installed already (the package will just be called "gdb"). If the broken application is called "brokenapp":

gdb brokenapp

A paragraph about copyright and licensing will appear, and at the end a prompt with the cursor:

(gdb) _ 

Type run and hit enter. If you need to supply arguments (e.g. -x --foo=bar whatever) append those (run -x --foo=bar whatever). The program will do what it does, you will see the output and if you need to interact you can (note you can run any sort of program, including a GUI one, inside gdb). At the point where it usually segfaults you will see:

Program received signal SIGSEGV, Segmentation fault.
0x00000000006031c9 in ?? ()
(gdb) _

The second line of output here is just an example. Now type bt (for "backtrace") and hit enter. You'll see something like this, although it may be much longer:

(gdb) bt
#0  0x00000000006031c9 in ?? ()
#1  0x000000000040157f in mishap::what() const ()
#2  0x0000000000401377 in main ()

If it is longer, you'll only get a screenful at a time and there will be a --More-- message. Keep hitting enter until it's done. You can now quit, the output will remain in your terminal. Copy everything from Program received signal SIGSEGV onward into a text file, and file a bug report with the application's bug tracker; you can find these online by searching, e.g. "brokenapp bug report" -- you will probably have to register so a reply can be sent to you by email. Include your description of the problem, any arguments you supplied to run, etc., and a copy of the backtrace (if it is very long, there may be a means to attach a text file in the bug tracker interface). Also include the version, if you know what it is (brokenapp --version may work, or the man page may indicate how to get this), and which distribution you are using.

Someone will hopefully get back to you in not too long. Filing bugs is a usually appreciated.

Solution 2

This means that application has a bug.

• If you are a end-user, you should contact the vendor of the application.

  • If it came with a Linux distribution, your should create a bug report for that distribution.
  • For third-party non-commercial apps you should report the bug to the author or this particular application bug tracker. Usually you could find place by browsing application site or downloaded binary/source package.
  • For commercial apps you should contact the support.

• If it is your own application, you can:

  1. enable core files: $ ulimit -c unlimited
  2. reproduce the crash: $ ./yourapp
  3. debug crash with gdb: $ gdb ./yourapp core

Core files will also be very useful for the developers other than yourself - they contain full state of the program at the moment of the crash; if you are going to file a bug report, attach them, and in some cases your app binary. Be aware that there is small chance that your personal data like account numbers, passwords and similar could remain in memory of the program at the moment of the crash. In many cases, reporting just backtrace of crashed thread is big help for developers to find the problem. To get backtrace, you could load core file with debugger (like gdb executable corefile).

Comments

[Kaz]

According to Microsoft's dialog box, you should only contact your vendor "if the problem persists", otherwise don't bother. Rare crashes are not real bugs, only reproducible ones.

[gena2x]

My observation is that quality of Microsoft software is low in lot of cases in comparison the UNIX software, and it's nice that in UNIX world people usually don't refer to their guidelines.

[Ludwig Schulze]

Segmentation fault can occur also in interpreters languages (through that's mostly because bugs in the interpreter itself),

[lesolorzanov]

This is super useful! Is there a possibility to step inside? put a stop mark and try to find out more?

[goldilocks]

@ZloySmiertniy gdb does a lot of stuff. You want to click through to section 5.1

[Oleg Kokorin]

especially useful clear explanation on how to pass execution arguments, thanks