Hi,
On Thu, 29 Jul 2010, Philipp wrote:
> On a more general note: I got ecasound to crash a number of times, with
> different messages (soft-assert something, segfault). Which information
> is most useful for debugging? Does it help to run ecasound with -ddd and
> provide the output? Something else?
these are always interesting. The soft asserts are definitely interesting
(as they hint that code is running paths the original design did not
anticipate -> not necessarily trouble, but in many cases is). A log with
'-ddd' usually a good way to describe the context. These are often enough
to start hunting the bug. Even better if you have the command-line, or set
of interactive-commands, to reproduce the problem.
And even better still is if you can reproduce the problem with a
standalone example (e.g. using "rtnull" in place of JACK/ALSA, "null" or
"tone" instead of actual files). This way anyone can try your case without
having your full session replicated (e.g. possibly gigabytes of audio
files), nor having similar audio hardware, etc, etc. The contents of the
audio files rarely matter, but often times it's important to have input
files of certain length and with certain audio parameters to trigger the
bug (and for this, the "tone" input object, together with "select" and
"playat", is really nice).
But, but, you can always start with a minimal bugreport to this list (e.g.
send a mail copy-n'pasteing the soft-assert), and if that does not seem
like enough, then dig up more details.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Thu Aug 19 00:15:02 2010
This archive was generated by hypermail 2.1.8 : Thu Aug 19 2010 - 00:15:02 EEST