What does it mean?
See AU: What is a segmentation fault? post and also this post which have some examples how reproduce it, SO: What is segmentation fault?.
The simplest description I can come with (may be not the perfect):
The program tried to access a memory area out side its own section. Operating system blocks it.
Some cases: Reading value with uninitialized pointer, Going out of range in an array, Function call (when backward compatibility not maintained), ...
However, it is not always easy find the cause with large programs or those which relay on other project lib's. And most of the cases end up with a bug report, either for target program or one of its dependencies (either upstream project or downstream distribution package).
How can I resolve this issue?
Fire a bug report
If you didn't make any custom configuration/setup and you all updates installed. fire a bug report, see How do I report a bug?
If open source supported by Ubuntu use
apport-bug). For 3rd party closed source, check their help pages how to report bugs and collect related data.
Take initiative to debug
If you you have even a little programming background, it is recommended that you try your best to resolve it yourself. There many bug reports out there inactive for years. At least, you may be able to collect enough debug data that help resolve the issue when reporting it.
That's means that you are breaking the user abstraction level and opening the black box! (FLOSS actually has transparent box).
Some Useful Tools for Debugging
Some ... I mean there are many other useful tools out there that you gonna find when you dig in more.
apport-bug logs / core dump / backtrace
If you don't have an error message before segmentation fault. Run it with
--save option and look for back-trace log:
apport-bug program-cmd --save bug-report_output.txt
gdb backtrace / debuging source code
If it didn't work, use
$ gdb program-cmd
If you get any error message, check the web, launchpad and in upstream project bug tracker if there any similar cases.
For some advanced users or who are following a c/c++ learning path, they could download the corresponding
-dbg symbols packages. Then you can use
gdb to trace program flow through the source and get the exact function/instruction that raise the runtime error.
For Ubuntu(Debian) based distributions, source code of a package can be downloaded using:
apt-get source <package-name>
strace system call tracing
Another tool that may help is
strace, I like it. It's really a powerful tool.
It presents itself:
In the simplest case
strace runs the specified command until it exits. It intercepts and records the system calls which are called by a
process and the signals which are received by a process. The name of each system call, its arguments and its return value are printed on
standard error or to the file specified with the -o option.
strace is a useful diagnostic, instructional, and debugging tool. System administrators, diagnosticians and trouble-shooters will find it
invaluable for solving problems with programs for which the source is not readily available since they do not need to be recompiled in
order to trace them. Students, hackers and the overly-curious will find that a great deal can be learned about a system and its system
calls by tracing even ordinary programs. And programmers will find that since system calls and signals are events that happen at the
user/kernel interface, a close examination of this boundary is very useful for bug isolation, sanity checking and attempting to capture
ltrace dynamic library call tracing
ltrace is a program that simply runs the specified command until
exits. It intercepts and records the dynamic library calls which are
called by the executed process and the signals which are received by
that process. It can also intercept and print the system calls exe‐
cuted by the program.
Its use is very similar to