gstreamer/docs/faq/troubleshooting.xml
Stéphane Loeuillet e29a848ad4 docs/faq/dependencies.xml: typo
Original commit message from CVS:
* docs/faq/dependencies.xml: typo
* docs/faq/getting.xml :
- fix download URL for new gstreamer site
- hide sf.net download page as latest version aren't there
- fix apt URLs
- fill "get via CVS" paragraph (link to dev page on the site)
* docs/faq/general.xml:
hide status tables as they no more exists
change case on plugins license file to reflect reality
* docs/faq/troubleshooting.xml:
remove the wiki question/answer as there is no more wiki
2004-04-30 21:29:06 +00:00

176 lines
6.2 KiB
XML

<sect1 id="chapter-troubleshooting">
<title id="title-troubleshooting">Troubleshooting GStreamer</title>
<qandaset>
<qandaentry>
<question id="troubleshooting-undefined-behaviour">
<para>
My GStreamer-based application crashes on startup with errors about unfound
schedulers on the command-line. I get undefined behaviour as soon as any
GStreamer element is being initialized.
</para>
</question>
<answer>
<para>
Your registry is probably missing, or it is outdated (i.e. not updated after
a recent upgrade). Fix this by running gst-register yourself:
<programlisting>
gst-register
</programlisting>
In the worst case, you might have to run it both as user and as root.
</para>
<para>
Note that package managers are suggested to run this automatically during the
post-installation. Our RPMs and Debian packages do just that.
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="troubleshooting-missing-plug-in">
<para>
Some application is telling me that I am missing a plug-in. What do I do ?
</para>
</question>
<answer>
<para>
Well, start by checking if you really are missing the plug-in.
<programlisting>
gst-inspect (plug-in)
</programlisting>
and replace (plug-in) with the plug-in you think is missing.
If this doesn't return any result, then you either don't have it or your
registry cannot find it.
</para>
<para>
If you're not sure either way, then chances are good that you don't have
it. You should get the plug-in and run gst-register to register it.
How to get the plug-in depends on your distribution.
<itemizedlist>
<listitem><para>if you run GStreamer using packages for your distribution, you
should check what packages are available for your distribution and see
if any of the available packages contains the plug-in.
</para></listitem>
<listitem><para>if you run GStreamer from a source install, there's a good chance
the plug-in didn't get built because you are missing an external library.
When you ran configure, you should have gotten output of what plug-ins are
going to be built. You can re-run configure to see if it's there.
If it isn't, there is a good reason why it is not getting built.
The most likely is that you're missing the library you need for it.
Check the README file in gst-plugins to see what library you need.
Make sure to remember to re-run configure after installing the supporting
library !
</para></listitem>
<listitem><para>
if you run GStreamer from CVS, the same logic applies as for a source install.
Go over the reasons why the plug-in didn't get configured for build.
Check output of config.log for a clue as to why it doesn't get built if
you're sure you have the library needed installed in a sane place.
</para></listitem>
</itemizedlist>
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="troubleshooting-old-plug-ins">
<para>
I get an error that says something like
(process:26626): GLib-GObject-WARNING **: specified instance size for type
`DVDReadSrc' is smaller than the parent type's `GstElement' instance size
What's wrong ?
</para>
</question>
<answer>
<para>
If you run GStreamer CVS uninstalled, it means that something changed in
the core that requires a recompilation in the plugins. Recompile the
plugins by doing "make clean &amp;&amp; make".
</para>
<para>
If you run GStreamer installed, it probably means that you run the plugins
against a different (incompatible) version than they were compiled against,
which ususally means that you run multiple installations of GStreamer.
Remove the old ones and - if needed - recompile again to ensure that it is
using the right version.
</para>
<para>
Note that we strongly recommend using Debian or RPM packages, since you will
not get such issues if you use provided packages.
</para>
</answer>
</qandaentry>
<qandaentry>
<question id="troubleshooting-segfault">
<para>
The GStreamer application I used stops with a segmentation fault. What can
I do ?
</para>
</question>
<answer>
<para>
There are two things you can do. If you compiled GStreamer with specific
optimization compilation flags, you should try recompiling GStreamer,
the application and the plug-ins without any optimization flags. This allows
you to verify if the problem is due to optimization or due to bad code.
Second, it will also allow you to provide a reasonable backtrace in case
the segmentation fault still occurs.
</para>
<para>
The second thing you can do is look at the backtrace to get an idea of where
things are going wrong, or give us an idea of what is going wrong.
To provide a backtrace, you should
<orderedlist>
<listitem><para>
run the application in gdb by starting it with
<programlisting>
gdb (gst-application)
</programlisting>
(If the application is in a source tree instead of installed on the system,
you might want to put "libtool" before "gdb")
</para></listitem>
<listitem><para>
Pass on the command line arguments to the application by typing
<programlisting>
set args (the arguments to the application)
</programlisting>
at the (gdb) prompt
</para></listitem>
<listitem><para>
Type "run" at the (gdb) prompt and wait for the application to
segfault. The application will run a lot slower, however.
</para></listitem>
<listitem><para>
After the segfault, type "bt" to get a backtrace. This is a stack of
function calls detailing the path from main () to where the code is
currently at.
</para></listitem>
<listitem><para>
If the application you're trying to debug contains threads, it is also
useful to do
<programlisting>
info threads
</programlisting>
and get backtraces of all of the threads involved, by switching to
a different thread using "thread (number)" and then again requesting
a backtrace using "bt".
</para></listitem>
<listitem><para>
If you can't or don't want to work out the problem yourself, a copy and paste
of all this information should be included in your
<link linkend="using-bugs-where">bug report</link>.
</para></listitem>
</orderedlist>
</para>
</answer>
</qandaentry>
</qandaset>
</sect1>