Re: [Lmuse-developer] [muse-sequencer/muse] muse3 just stopped working (#548)

[termtech <ter...@ro...>]

On Tuesday, November 8, 2016 6:25:32 PM EST you wrote:
> Try emailing me directly and attaching it, without CC'ing the list.

[ File was received. ] 

Oh crud.
DrumGizmo made significant changes to their semaphore code 
 from 0.9.10 to 0.9.11

The supplied file runs fine with 0.9.10 but crashes with 0.9.11

The error is from within DrumGizmo.
But it is /triggered/ by MusE. Ardour works fine.

Whether we run MusE with or without audio (-a switch), it crashes.

According to the call stack, DrumGizmo crashes at semaphore.cc:152,
 in method Semaphore::wait(), in a sem_timedwait() block, with an error 
 /other/ than timeout, while waiting. In version 0.9.10 that method's 
 code was much simpler, with simply a sem_wait(&prv->semaphore) call.

Now, also according to the call stack, another thread is sitting in a
 futex_wait(). This futex_wait is caused by MusE calling
 seteuid() from globals.cpp:doSetuid() which is called from 
 our jack.cpp:jack_thread_init() if Jack is running, or from
 calling seteuid() in globals.cpp:undoSetuid() from 
 dummyaudio.cpp:dummyLoop() if Jack is not running 
 (the -a switch dummy audio driver).

Each time I try with Jack or our dummy audio, the crash happens,
 and that futex_wait() call is sitting there in the other thread !

So... Over the years I have wondered if we really need that setuid()
 crap anymore? That was waaaay back in prehistoric Jack and kernel days.
Our (outdated?) README file states that MusE needs to be run at 
 the same uid as Jack. Is this really necessary still?

I have not delved into it more because it didn't seem to break anything.
But now... I will look closer and try removing those setuid() calls.

Hey funkmuscle: You are on their forum. Can you let them know 
 what's happening here, keep them in the loop, so to speak?
Maybe they can offer some advice since version 0.9.11 + MusE breaks.
Meanwhile I will try to fix it here by removing those setuid() calls...

Thanks.
Tim.