Core dump when leaving MusE

[kybos]

Occasionally I get a segmentation fault at leaving:

Muse: Exiting ALSA midi
Muse: Cleaning up temporary wavefiles + peakfiles
MusE: Exiting Dsp
MusE: Exiting OSC
MusE: Deleting icons
MusE: Deleting all parentless dialogs and widgets
app.exec() returned:0
Deleting main MusE object
./b: line 2: 26094 Segmentation fault      (core dumped) muse3 -aCpSNI2D

I loaded the dump and it shows that it occurs in audio.cpp:

unsigned int Audio::curFrame() const
      {
      return MusEGlobal::audioDevice->framePos();    <===========================

Any idea what the reason could be?

Call stack:

1   MusECore::Audio::curFrame                                      audio.cpp   1973 0x7f68c0e8138a 
2   MusEGui::EventCanvas::keyPress                                 ecanvas.cpp 437  0x7f68bbfeaa02 
3   (anonymous namespace)::libdivide::libdivide_s32_branchfree_gen libdivide.h 1256 0x7f68bbfe7c7f 
4   (anonymous namespace)::libdivide::libdivide_internal_s64_gen   libdivide.h 1484 0x7f68bbf9ef83 
5   (anonymous namespace)::libdivide::libdivide_internal_s64_gen   libdivide.h 1486 0x7f68bbf9efac 
6   QObjectPrivate::deleteChildren()                                                0x7f68bdcb913b 
7   QWidget::~QWidget()                                                             0x7f68bea44d5c 
8   QWidget::~QWidget()                                                             0x7f68bea44f99 
9   QObjectPrivate::deleteChildren()                                                0x7f68bdcb913b 
10  QWidget::~QWidget()                                                             0x7f68bea44d5c 
11  MusEGui::Splitter::~Splitter                                   splitter.h  38   0x7f68bf81cd0c 
12  MusEGui::Splitter::~Splitter                                   splitter.h  38   0x7f68bf81cd2e 
13  QObjectPrivate::deleteChildren()                                                0x7f68bdcb913b 
14  QWidget::~QWidget()                                                             0x7f68bea44d5c 
15  MusEGui::Splitter::~Splitter                                   splitter.h  38   0x7f68bf81cd0c 
16  MusEGui::Splitter::~Splitter                                   splitter.h  38   0x7f68bf81cd2e 
17  QObjectPrivate::deleteChildren()                                                0x7f68bdcb913b 
18  QWidget::~QWidget()                                                             0x7f68bea44d5c 
19  QWidget::~QWidget()                                                             0x7f68bea44f99 
20  QObjectPrivate::deleteChildren()                                                0x7f68bdcb913b 
... <More>                                                      

[terminator356]

Was that using Jack backend or Dummy backend driver?
I have observed a few crashes with the Dummy driver.
Hm, looks like the driver is still running... Should be shut down by then... I'll take a look.
And... Curious, what is that keypress event doing there?
Did you shut down by using key presses?
And if so why did it show up so late in the trace?

[kybos]

It was the dummy driver (muse3 -aCpSNI2D).
Thinking about it, I probably pressed Ctrl-C to shut down, because otherwise it takes so long to end with the dummy driver (it's on another PC in a VM).

[terminator356]

According to the code a shortcut was pressed, either
SHRT_SEL_RIGHT or SHRT_SEL_RIGHT_ADD which are
Qt::Key_Right and Qt::Key_Right + Qt::SHIFT.

Strange.
From a normal terminal Ctrl-C just immediately quits
But even from a VM, I fail to see how Ctrl-C could tell MusE to initiate a clean shutdown like that.
[ Edit ] Unless LASH session manager is involved. I notice you don't have the -L option to disable it.

BTW I received a wee donation moments ago. First one in like five years !
That wouldn't be you by any chance? If so, thank you kindly.

[kybos]

It was not me, sorry ;-).

I don't use LASH, and I am sure I did not press anything except Ctrl-C on leaving...