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 |