View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0007678ardourbugspublic2018-11-01 08:282019-01-23 12:05
Reporterjohne53 Assigned To 
PriorityhighSeverityfeatureReproducibilityalways
Status assignedResolutionopen 
PlatformAll 
Product Version5.12 
Summary0007678: Snapshots cannot be loaded if tooltips are disabled
DescriptionReported by a user called Tassy on the Mixbus forum:-

http://mixbus.harrisonconsoles.com/forum/thread-6634.html

His initial post includes a demonstration video but unfortunately, it's only viewable of you're a member of the MB forum! However... in a nutshell, users have discovered that snapshots cannot be loaded if they have tooltips disabled (i.e. the snapshots can't even be selected in MB's opening dialog).

I've confirmed that this affects Ardour too - and it's apparently present on all platforms.
Steps To Reproduce1) In 'Preferences->Appearance' disable the option to 'Show tooltips if mouse hovers over a control'

2) Restart Ardour.

3) On the opening dialog, if any session has snapshots, try to select one.
TagsNo tags attached.

Activities

x42

2018-11-01 22:22

administrator   ~0020437

Possible fix/workaround in 6.0-pre0-1226-gb81fdeaa6 -- tested on linux only so far.

johne53

2018-11-02 13:17

reporter   ~0020441

Last edited: 2018-11-02 16:13

 Hi Robin, I've only tested in Mixbus but let's assume Ardour is the same. Basically, it only works as long as I don't change the tooltips setting. Try the following steps:-

1) With tooltips set to disabled, launch Mixbus and load a session.
2) Open the Preferences window, enable tooltips, then close the window.
3) Use 'Session->Close' to close the session (whilst leaving Mixbus open). This will cause the Session Open dialog to re-appear.
4) Selecting a snapshot and clicking 'Open' will then crash Mixbus.

[Edit...] Hmmm... I just tried this in Ardour but I don't see the crash in Ardour - yet it's totally consistent in Mixbus :-(

[Edit2...] Okay, this isn't quite as simple as I thought... this never crashes if I run from within my debugger - but - if I run as a standalone app (i.e. running normally) even Ardour will crash about 15% - 20% of the time. It just doesn't crash 100% of the time (which Mixbus does). Some kind of race condition maybe?

johne53

2018-11-03 07:59

reporter   ~0020443

Hi Robin, I wonder if this is significant..?

Commit #bf18deaa66 modified certain files - the (four) modifications of interest are:-

    gtk2_ardour/editor_regions.cc
    gtk2_ardour/mixer_ui.cc
    gtk2_ardour/session_dialog.cc (2 x modifications)

and each modification takes the form:-

    if (UIConfiguration::instance().get_use_tooltips()) {
          whatever.set_tooltip_column(whatever);
    }

If I launch Ardour and load a session, initially all four instructions get processed. But after changing the tooltips setting, closing the session, then re-loading - only the instructions in 'session_dialog.cc' get re-run. So class 'SessionDialog' will be aware of the new state - whereas class 'Mixer_UI' won't be aware of the change and neither will class 'EditorRegions'. Maybe it's one of them that's causing the crash, rather than the session dialog?

x42

2018-11-03 12:02

administrator   ~0020445

Thanks for confirming that his indeed works around the issue. I still need to try with Ardour's patched gtk that alters treeview behavior when clicking, relevant for the EditorRegions.

I still do not understand why or how disabling tooltips using
  gtk_rc_parse_string ("gtk-enable-tooltips = 0");
has any effect on and treeview selection at all.

I wasn't able to reproduce the described issue, in the first place.

Snapshot loading worked just fine. However with disabled tooltips there was an immediate selection of the parent, when expanding the treeview and a 2nd click to select a child was interpreted as double-click on the parent if it was made too fast. Also this issue is only present when using the mouse. Perhaps some timeout related bug in gtk (double-click vs tooltip timeout) when a tooltip-colum is set.

If you have any insights there, they would be very welcome.


You are correct that there is currently no check in Mixer_UI::parameter_changed() or EditorRegions that un/sets the tooltip column dynamically. If this workaround is to stay, then those should be added.

johne53

2018-11-03 14:50

reporter   ~0020446

Last edited: 2018-11-03 14:52

 Okay, I've managed to get slightly further with this. The crash happens at this line in 'Session::remove_controllable(Controllable* c)'

    Controllables::iterator x = controllables.find (boost::shared_ptr<Controllable>(c, null_deleter()));

and it happens because 'c' is in fact a deleted object.

Now here's the strange thing... if I open the Preferences dialog but I don't change anything, that function doesn't get called - not even if I later close the snapshot and re-load it - BUT - if I open the Preferences dialog and change the tooltips setting, that function gets called next time I close the snapshot and then open one again (even the same one). I must admit, this isn't making much sense to me :-(

x42

2018-11-03 14:56

administrator   ~0020447

Crash? I wasn't aware that it crashes at all. I thought it's a selection issue.

johne53

2018-11-03 16:00

reporter   ~0020448

Yes, it's been crashing since you made your changes in commit #b81fdeaa66:-

http://tracker.ardour.org/view.php?id=7678#c20441

What's confusing me though is that I can't see any obvious connection between the changes and the crash - except (maybe) for the fact that some parts of the program will now recognise a newly updated tooltips state, whereas others won't.

johne53

2018-11-04 08:33

reporter   ~0020449

Hi Robin - I know this won't make much sense but the problem seems to originate at this line (the d'tor for class PBD::Controllable) :-

    virtual ~Controllable() { Destroyed (this); }

This generates a signal which ends up calling the function I mentioned in post 0020446 - Session::remove_controllable (Controllable* c)

Parameter 'c' is an object which is in the process of getting destroyed. What's weird is that this code seems to have been around for at least the past 10 years and there's no obvious connection with tooltips.

I'm wondering if this is just a co-incidence where two unrelated changes have altered some timing somehow?

x42

2018-11-05 03:13

administrator   ~0020453

Do you have a recipe how to produce this crash? or a backtrace?

johne53

2018-11-05 10:23

reporter   ~0020459

Yes, I described the steps a bit earlier (post #0020441). Over the past couple of days though, I've been using git blame to see if I could identify when this problem started. Up to now I've gone back as far as August and the crash is already there. It's just that the other bug (i.e. the faulty TreeView selection) has the effect of hiding the crash by making it more difficult to reproduce the steps needed to create it.

So I can say with certainty that the crash hasn't been caused by your recent changes. It's a long standing bug that just never showed up before. Interestingly, as I go further back, the bug shows up less frequently - which suggests to me that it might timing related (see my last post).

And on the subject of timing... is it definitely safe to generate a signal and pass an object that's just about to go out of scope? 'Session::remove_controllable()' does implement a mutex (while the object is being found) but my guess is that it already went out of scope, just before the mutex got reached.

johne53

2018-11-05 17:17

reporter   ~0020461

Last edited: 2018-11-05 17:23

 johne53 wrote:
" is it definitely safe to generate a signal and pass an object that's just about to go out of scope? "

AFAICT our 'Destroyed' signal gets connected using PBD::Signal::connect_same_thread(). So (in theory at least) it should be safe for Controllable::~Controllable() to pass a 'this' object - even if 'this' is only microseconds away from getting destroyed.

So I'm afraid that's me out of ideas... :-(

johne53

2018-11-07 09:36

reporter   ~0020462

Okay, after a bit more investigation I realised that most of the above is probably just an unhappy coincidence. The crash is actually caused by an unhandled exception in PortManager::register_port() (libs/ardour/port_manager.cc) but by the time the OS intervenes, there's another thread handling a Controllable::Destroyed signal (so that's where it appears to crash...)

PortManager::register_port() contains the following section:-

    catch (PortRegistrationFailure& err) {
        throw err;
    } catch (std::exception& e) {
        throw PortRegistrationFailure(string_compose(
                _("unable to create port: %1"), e.what()).c_str());
    } catch (...) {
        throw PortRegistrationFailure("unable to create port (unknown error)");
    }

Note that these lines catch certain exceptions and re-throw some new ones - but nothing catches the re-thrown ones. In this particular case, a std::exception is getting caught although I can't figure out what generates it. The actual error is "unable to create port: failed constructor" and the port name is "click/audio_out 1"

Dunno if that gets us any further..? Maybe this is just an issue on my particular system?

johne53

2018-11-08 09:04

reporter   ~0020465

Last edited: 2018-11-08 09:09

 Okay, I'm gradually getting a bit closer with this one...

johne53 wrote:
" Note that these lines catch certain exceptions and re-throw some new ones - but nothing catches the re-thrown ones. "

Actually, that's not 100% true - any 'PortRegistrationFailure' exceptions WILL get caught by these lines in 'IO::ensure_ports_locked()' :-

    catch (AudioEngine::PortRegistrationFailure& err) {
        /* pass it on */
        throw;
    }

but like last time, this simply re-throws a new exception. It's the re-thrown exception which never gets caught. However, while examining IO::ensure_ports_locked() I noticed that this code appears quite regularly in io.cc:-

#ifndef PLATFORM_WINDOWS
    assert (!AudioEngine::instance()->process_lock().trylock());
#endif

which suggests to me that this code is running locked (for the non-Windows platforms) but unlocked on Windows. My gut feeling is that this is most likely the reason for the problem. It's definitely timing related and I can eliminate the problem just by adding various things which change the timing (e.g. bits of debugging code).

johne53

2018-11-08 12:14

reporter   ~0020466

johne53 wrote:
" I noticed that this code appears quite regularly in io.cc:-

 #ifndef PLATFORM_WINDOWS
     assert (!AudioEngine::instance()->process_lock().trylock());
 #endif

which suggests to me that this code is running locked (for the non-Windows platforms) but unlocked on Windows. "

No, it's also locked on Windows - but according to commit #6542ce76d0 (Jul 13th 2013) the assertions fail on Windows because the call to 'trylock()' doesn't work... :-(

johne53

2019-01-22 12:05

reporter   ~0020573

Did we ever do anything to fix this? (I can't seem to reproduce the crash any more...)

x42

2019-01-23 12:05

administrator   ~0020576

The reported issue "Snapshots cannot be loaded if tooltips are disabled" was addressed.

I guess the crash is a different unrelated issue. but "unable to create port.." is known to cause crashes. Perhaps keeping the preference dialog detached and visible causes this indirectly (some port shared_ptr<> reference is kept)

Issue History

Date Modified Username Field Change
2018-11-01 08:28 johne53 New Issue
2018-11-01 22:22 x42 Note Added: 0020437
2018-11-01 22:22 x42 Assigned To => x42
2018-11-01 22:22 x42 Status new => feedback
2018-11-02 13:17 johne53 Note Added: 0020441
2018-11-02 13:17 johne53 Status feedback => assigned
2018-11-02 15:53 johne53 Note Edited: 0020441
2018-11-02 15:53 johne53 Note Edited: 0020441
2018-11-02 15:54 johne53 Note Edited: 0020441
2018-11-02 15:54 johne53 Note Edited: 0020441
2018-11-02 15:54 johne53 Note Edited: 0020441
2018-11-02 16:13 johne53 Note Edited: 0020441
2018-11-02 16:13 johne53 Note Edited: 0020441
2018-11-03 07:59 johne53 Note Added: 0020443
2018-11-03 12:02 x42 Note Added: 0020445
2018-11-03 12:03 x42 Assigned To x42 =>
2018-11-03 14:50 johne53 Note Added: 0020446
2018-11-03 14:51 johne53 Note Edited: 0020446
2018-11-03 14:52 johne53 Note Edited: 0020446
2018-11-03 14:56 x42 Note Added: 0020447
2018-11-03 16:00 johne53 Note Added: 0020448
2018-11-04 08:33 johne53 Note Added: 0020449
2018-11-05 03:13 x42 Note Added: 0020453
2018-11-05 10:23 johne53 Note Added: 0020459
2018-11-05 17:17 johne53 Note Added: 0020461
2018-11-05 17:23 johne53 Note Edited: 0020461
2018-11-07 09:36 johne53 Note Added: 0020462
2018-11-08 09:04 johne53 Note Added: 0020465
2018-11-08 09:09 johne53 Note Edited: 0020465
2018-11-08 12:14 johne53 Note Added: 0020466
2019-01-22 12:05 johne53 Note Added: 0020573
2019-01-23 12:05 x42 Note Added: 0020576