Bug 87412

Summary: Weston now silently quits when the user specifies to load desktop-shell.so
Product: Wayland Reporter: nerdopolis1
Component: westonAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED NOTABUG QA Contact:
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description nerdopolis1 2014-12-17 12:49:46 UTC
I think it's due to commit 01e98b65c6d526edf6cfbd22d254bd7804bf8790 in Weston, as there is one error "Module desktop-shell.so is already loaded", This is probably because Weston is loading it by default, and now due to the commit, it causes Weston to see it as a module load fail, and it quits
Comment 1 nerdopolis1 2014-12-17 13:01:15 UTC
I forgot to mention this seems to happen when specified in both weston.ini, and on the command line
Comment 2 Pekka Paalanen 2014-12-17 13:23:19 UTC
What is your test case exactly? How do you specify it?

Note, that desktop-shell.so is a shell module, which must be loaded by --shell option or [core] 'shell' key in weston.ini. Trying to load it via modules is a user mistake.

Is there any case where one cannot easily avoid loading the same module twice?

Should we make "module already loaded" look more like an error?
Comment 3 nerdopolis1 2014-12-17 14:44:31 UTC
I was accidentally specifying desktop-shell in --modules with my scripts... I guess it could appear to be more of an error, but I dont think loading a duplicate module that previously only got ignored is worthy of causing Weston to exit.
Comment 4 Yong Bakos 2016-04-25 01:19:24 UTC
I'd like to vote for this bug to be closed.

The --modules option is documented, in its man, to be used only for testing. A developer using the --modules option would know to simply re-run weston without specifying the particular module.

End-users incorrectly passing an 'invalid' module as a --modules option would be advised to observe what is documented in man.

The original context of this bug is due to incorrectly specifying a --shell module as a --modules option.

Otherwise, to honor this use case, we'd have to implement additional logic in compositor.c that:

1) Checks the module to be sure it is a valid option for --modules, and if it isn't, prints a helpful message before quitting.
2) Ignores the loading of the valid, specified --modules module and continues, rather  than causing weston_load_module to return NULL and quitting.
Comment 5 Pekka Paalanen 2016-04-25 09:08:35 UTC
We could also make Weston discriminate between module types (backend, shell, generic) by having a type-specific symbol name instead of just "module_init", which would help weston quit with a better error message. I still think quitting is the right thing to do.

Closing.

If you want better errors, that would be a new report. Preferably a new Task in Phab.fd.o.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.