Including extension debugdevice (debugoutput) twice causes SIGABRT

[pvmm]

In an assert in src/settings/SettingsManager.cc:

openmsx: src/settings/SettingsManager.cc:34: void openmsx::SettingsManager::registerSetting(BaseSetting &): Assertion `!settings.contains(setting.getFullNameObj())' failed.

but I suppose it should be simple to stop duplicate registration from happening in
MSXCommandController::registerSetting(Setting& setting)

[m9710797]

Thanks for reporting!

That assertion is only the symptom, instead we should fix the root cause. I mean if we would change this so that duplicate registrations do become legal, it would make finding futures bugs harder.

In this specific case the problem is that 2 DebugDevice instances both create a setting with the same name. Two identically configured debug devices aren't very useful(*1). Instead they should each have their own separate setting.

In most cases we've solved this problem by instead of using a fixed setting name (in this case "debugoutput"), use a calculated setting name. And then typically we calculate this setting name based on MSXDevice::getName() (because this name is already made unique among the different instances).

A typical example could be getName() + " output". That would result in the name Debug Device output for the 1st instance and Debug Device(2) output for the 2nd instance, and so on.

This would have been my preferred solution, but now I am concerned about backwards compatibility: the setting name for the 1st (and typically only) device would change from debugoutput to Debug Device output. I don't know how many people actually change the value of this setting. By default the value is "stdout", and most of the time (always?) when I see people use the DebugDevice they are using "stdout".

So maybe breaking backwards compatibility is not a big problem here? Also only developers use the DebugDevice, and maybe we can ask for more adaptability from such users than from more casual openMSX users?

Anyway, the alternative is maybe to check if the current MSXDevice name is "Debug Device" and then use the old setting name. And in all other cases use a calculated setting name. That's ugly but it's backwards compatible. I have no strong preference. Maybe breaking backwards compatibility is OK in this case???

@pvmm: are you willing to and do you have time to work on such a fix? Or else I could put it on my TODO list (though with low priority).

(*1) You could say that using 2 debug devices is never useful, even if 1 of the 2 is reconfigured (by editing the xml file) to use different IO ports. But that's a matter of opinion. In any case openMSX shouldn't crash when a user does try this.