On Wednesday, November 9, 2016 6:24:37 PM EST termtech wrote: > 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.
OK Try it now! In git master. Here's the ChangeLog: Removed seteuid()/setreuid() code supporting ancient givertcap tool (kernel priveleges). [Yeah I forgot to mention before that this stuff is support for the old "givertcap" tool.] Was interfering with DrumGizmo's use of semaphores. TODO: Remove further old rtcaps code such as main.cpp:getCapabilities(). Tested OK so far, with self- or externally- started Jack, or dummy audio driver, and as root user as well, and with Jack running non-realtime. Note: This may also prevent things like our RTC timer code from accessing the RTC as non-root, but RTC is old and should be replaced anyway, and it usually required 'poking' it beforehand in a terminal anyway - unless MusE is run as root which still works as always. Tim. ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Lmuse-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lmuse-developer
