Closed athos-ribeiro closed 2 years ago
The issue happens due to injection of the -Bsymbolic-functions
LDFLAGS in Ubuntu. This is definitely an issue to be discussed for the packaging then. Sorry for the noise :)
Right, b29b5fd relies on the linker's default behavior to override library-provided symbols.
Using -Bsymbolic-functions
is probably some sort of optimization, avoiding unnecessary symbol lookups during startup. I wonder if we (as upstream) have some way to make sure that symbols like get_multipath_config
are treated with the default behavior even if other functions from the same library use -Bsymbolic_functions
.
Hints appreciated.
get_multipath_config()
and put_multipath_config()
are defined as weak symbols in the source code. My expectation was that weak symbols were unaffected by -Bsymbolic-functions
, but that's not the case. References to get_multipath_config()
are directly replaced by libmp_get_multipath_config()
by the linker, which is of course wrong.
I have found no way to annotate these functions such that they are exempted from -Bsymbolic-functions
. There are recent proposals to add a -Bsymbolic-non-weak-functions option, which might be just what we could use here, but they don't seem to be available yet.
@athos-ribeiro , after discussion with our toolchain experts, could you try this, and see if the error goes away?
LDFLAGS='-Wl,-Bsymbolic-functions -Wl,--export-dynamic-symbol=get_multipath_config -Wl,--export-dynamic-symbol=put_multipath_config'
The --export-dynamic-symbol
option should override the effect of -Bsymbolic-functions
. It worked in my testing, but I'd like you to confirm.
I've pushed a tentative patch to https://github.com/mwilck/multipath-tools/tree/dynamic-list. Please test if you're able to compile and run that code with LDFLAGS='-Wl,-Bsymbolic-functions'
.
I'm not going to make an official patch with -Wl,--dynamic-list
. In the meantime, I had a discussion with one of the toolchain maintainers at SUSE, and he came up with detailed explanation about -Bsymbolic-functions
and why it shouldn't be used. See this stackoverflow post.
Closing per previous comment.
The b29b5fd commit mentions that the config struct should be initialized with init_config.
Once b29b5fd is applied in Ubuntu's multipath-tools, the multipathd service no longer starts upon a system boot and a segmentation fault is thrown.
The situation improves once 6236b5a is applied, ensuring the service can start. However, the segmentation fault is still observed in specific cases such as upon autopkgtest runs of debian/tests/tgtbasedmpaths.
It seems that the issue is triggered in specific configuration read situations in multipathd. I am still working on a minimal reproducer.
This following patch fixes such occurrences by initializing the configuration file with the init_config, as suggested in b29b5fd.
Finally, here is a dump of the code path that is leading to the segfault: