Gentoo Archives: gentoo-user

From: Andreas Fink <finkandreas@×××.de>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] davfs2 suddenly not working properly
Date: Tue, 07 May 2019 20:08:46
Message-Id: 0LoHKz-1gmJeb0ZCb-00gD5E@smtp.web.de
In Reply to: Re: [gentoo-user] davfs2 suddenly not working properly by John Covici
1 On Tue, 07 May 2019 02:25:13 -0400
2 John Covici <covici@××××××××××.com> wrote:
3
4 > On Tue, 07 May 2019 01:58:25 -0400,
5 > Andreas Fink wrote:
6 > >
7 > > On Thu, 18 Apr 2019 10:14:13 -0400
8 > > John Covici <covici@××××××××××.com> wrote:
9 > >
10 > > > On Thu, 18 Apr 2019 03:20:25 -0400,
11 > > > Neil Bothwick wrote:
12 > > > >
13 > > > > [1 <text/plain; US-ASCII (quoted-printable)>]
14 > > > > On Wed, 17 Apr 2019 21:41:41 -0400, John Covici wrote:
15 > > > >
16 > > > > > Apr 17 18:39:55 ccs.covici.com systemd-coredump[5334]: Process
17 > > > > > 5332 (umount.davfs) of user 0 dumped core.
18 > > > > > Apr 17 18:39:55 ccs.covici.com systemd[1]:
19 > > > > > systemd-coredump@××××××××.service: Succeeded.
20 > > > > >
21 > > > > > I can't find that coredump, not sure if the process is allowed to
22 > > > > > do it.
23 > > > >
24 > > > > From the systemd-coredump man page:
25 > > > >
26 > > > > By default, systemd-coredump will log the core dump including a
27 > > > > backtrace if possible to the journal and store the core dump itself
28 > > > > in an external file in /var/lib/systemd/coredump.
29 > > > >
30 > > > > You can change this in /etc/systemd/coredump.conf
31 > > >
32 > > > Thanks, I found it, but the backtrace has no symbols, even though I
33 > > > have features set so that everything is compiled with symbols like
34 > > > this:
35 > > > FEATURES="${FEATURES} -stricter -distcc -ccache splitdebug buildpkg"
36 > > > I wonder what is happening here?
37 > > >
38 > > > Strange thing si I have seen nothing on bgo for this problem.
39 > > >
40 > >
41 > > I have the same problem on one of my machines. It segfaults somewhere
42 > > in strcmp with avx2 according to a backtrace.
43 > > Will try rebuilding my system libraries, since I changed lately from
44 > > "march=native" to "march=x86-64 mtune=generic". I thought I rebuilt
45 > > everything but there might be something missing for me.
46 > > Anyway, for me as a workaround this works: fusermount -u MOUNTPOINT
47 >
48 > OK, I will try that and see if it works.
49 >
50 > Thanks.
51 >
52
53 I was debugging the issue today, and it's a bug in davfs2 as it seems...
54 Line 151-153 in src/umount_davfs.c reads the following:
55 char *pid = NULL;
56 FILE *file = fopen(pidfile, "r");
57 if (!file || fscanf(file, "%a[0-9]", &pid) != 1 || !pid) {
58 This is something I don't even understand what it is supposed to do, because there is so
59 much wrong with it...
60 %a would read a floating point (we all know, PID's are floating points...)
61 The [0-9] is completely useless there..
62 The result is being saved in a char*...
63
64 You could write it like this:
65 char pid[32];
66 FILE *file = fopen(pidfile, "r");
67 if (!file || fscanf(file, "%s", pid) != 1) {
68 This would fix the segmentation fault.
69
70 And now the funny part: I wanted to report a bug, so I went to the website and wanted to
71 see in the source code repository when this bug was introduced. However in the source
72 code repository there is a correct implementation (similar to mine, actually more safe
73 than mine) BUT any released version I tested from 1.4.7 until 1.5.5 all have this wrong
74 implementation 1.4.7 was released in 2012, and the file src/umount_davfs.c wasn't changed
75 since 2 years according to the repository browser.
76 How the releases are correlating with the source code browser is at the moment beyound my
77 understanding of this project.
78 Anyone in contact with the development team of davfs2, who could shed some light on the
79 situation?
80
81 Cheers
82 Andreas