On Fri, 2020-12-04 at 21:55 +0800, Ian Kent wrote: > On Fri, 2020-12-04 at 18:23 +0800, Ian Kent wrote: > > On Thu, 2020-12-03 at 17:01 +0100, Jonathan Van den Broeck wrote: > > > Hi, > > > > > > Sorry in advance if it is not the right place for this type a > > > question, > > > I am tottally noob in mailing list. > > > > > > I try to use autofs on Solus 4.1 (http://getsol.us). It seems > > > there > > > is > > > some problem with their package since version 5.1.3 and I want to > > > help > > > to solve the issue but I cannot figure what is the problem. > > > > > > I have try on fedora without any problem so I compare two strace > > > to > > > see > > > the difference but it did not help me. It seems to crash when it > > > need > > > to read the map file. > > > > > > Here is a link the issue with the initial description of the > > > problem > > > and a link to the source build of the package : > > > https://dev.getsol.us/T9026 > > > https://dev.getsol.us/source/autofs/ > > > > In order to try and work out what's wrong it's necessary to know > > where the fault is occurring. > > > > That means you need to have debug symbols available one way or > > another. > > > > I don't know how that's done with Solus, in Fedora one installs > > the corresponding autofs-debuginfo and autofs-debusource packages. > > > > You might be able to get most of what's needed by changing the > > "environment:" line of the Solus package.yml and adding DEBUG=1 > > to the exported environment for the build but I don't really > > know the Solus build system works. > > Your out of luck here, I couldn't build a Solus package that had > an automount binary with debug symbols. > > > Once you have a package with debugging information you can examine > > the core dump using coredumpctl(1) which should be installed as > > part of systemd. > > Since the Solus autofs-dbginfo contains no debug symbols. > > > If you can get a build with debugging info then I can advise you > > further on how to get information about the crash, such as exactly > > where the fault occurred. > > And general area where this fails looks fine but I can't debug it > because of the above. > > I'm really not interested if struggling with this odd build system. In spite of, coredumps not being saved by systemd after a fresh install and the configuration looking like it should, package dbginfo packages not being produced during local builds, the distribution dbginfo package not containing any debugging information (might need a patch to set DONTSTRIP=1 in Makefile.conf.in but even that doesn't get full debug info in the built package, not sure how all that hangs together), I continued with this. It turns out that the initial crash occurs when trying to access a static global variable in the configuration handling code. This structure "has" been allocated and initialized and should be available to the configuration handling functions. However, since the functions know it is not NULL they don't check it before access, and at some point after the allocation and initialization it is seen as NULL and the program crashes. Removing the LDFLAGS option -Wl,-Bsymbolic-functions makes the problem go away. I'm not sure why this happens, the best I could find is this: https://stackoverflow.com/questions/7216973/is-there-a-downside-to-using-bsymbolic-functions/20729291 Ian
