Re: [ecasound] 2.7.1 hang when calling 'ecasound [ -h | --help ]'

Excerpts from Kai Vehmanen's message of 2010-07-11 11:19:01 +0200:
> Hi,
> On Fri, 9 Jul 2010, Philipp wrote:
>
> > It seems like ecasound doesn't quit properly after printing the help
> > page, so no matter whether I call it without arguments, with -h or
> > --help, it gets stuck and needs a SIGKILL.
>
> it would be very interesting to see a strace (e.g. "strace -p
> <pid-of-ecasound>" before you SIGKILL the process. This sounds really odd
> and I suspect this is something external to ecasound (e.g. connection JACK
> hanging, problem with a ALSA driver, or something similar)... at least I
> cannot reproduce this on any machine (and cannot remember such a problem
> with past versions of ecasound).

I dug a little deeper into the code yesterday and got a little further
in the codepath leading to the issue. Apparently the codepath following
state->retval = ECASOUND_RETVAL_INIT_FAILURE;
is where it happens. For example --version causes the same issue.
A friend suggested that it might have to do with pthread_something and
that it might be trying to kill a thread that was never created and
waits and waits...

Anyway, here's the strace:

$ strace -p 7617
Process 7617 attached - interrupt to quit
futex(0x7f2d3a1959e0, FUTEX_WAIT, 7618, NULL) = ? ERESTARTSYS (To be
restarted)
--- SIGTERM (Terminated) @ 0 (0) ---
rt_sigreturn(0xf) = -1 EINTR (Interrupted system
call)
futex(0x7f2d3a1959e0, FUTEX_WAIT, 7618, NULL <unfinished ...>
+++ killed by SIGKILL +++

I noticed that there are two processes running, so here's another run
with what probably is something like a subprocess (my terminology is
likely wrong, I know next to nothing about that stuff)

$ strace -p 7980
Process 7980 attached - interrupt to quit
rt_sigtimedwait([HUP INT QUIT PIPE TERM], NULL, NULL, 8) = 15
rt_sigprocmask(SIG_UNBLOCK, [HUP INT QUIT PIPE TERM], NULL, 8) = 0
madvise(0x7fbc80c9f000, 8368128, MADV_DONTNEED) = 0
_exit(0) = ?
Process 7980 detached

Alsa and Jack both seem to work, but only tested with:
$ ecasound -i null -o alsa -el:sine_fcac,440,1
$ ecasound -i null -o jack -el:sine_fcac,440,1
But with both I get that trace after ctrl+c that I wrote about in
another mail.

I asked another user of my distribution to try it, and he has the same
problem. He's also on x86_64. My distribution doesn't patch unless
necessary but always has very recent versions of basically everything,
so it seems like it this is once more the cause for trouble.
I don't know which external libraries are relevant in this case, here
are some:

kernel 2.6.34.1
gcc 4.5.0 (actually snapshot 4.5-20100610)
glibc 2.12
alsa-lib 1.0.23
jack in my case is tschack-git, but the other tester likely used
a different jack variant
audiofile 0.2.7
libsamplerate 0.1.7
readline 6.1.002

Tell me what you need to narrow it down further, debug builds and all
that stuff is no problem, just tell me what to do. Thanks for looking
into this.

-- 
Regards,
Philipp
--
"Wir stehen selbst enttäuscht und sehn betroffen / Den Vorhang zu und alle Fragen offen." Bertolt Brecht, Der gute Mensch von Sezuan
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Ecasound-list mailing list
Ecasound-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecasound-list