On Tue, 07 May 2019 02:25:13 -0400 John Covici <[email protected]> wrote:
> On Tue, 07 May 2019 01:58:25 -0400, > Andreas Fink wrote: > > > > On Thu, 18 Apr 2019 10:14:13 -0400 > > John Covici <[email protected]> wrote: > > > > > On Thu, 18 Apr 2019 03:20:25 -0400, > > > Neil Bothwick wrote: > > > > > > > > [1 <text/plain; US-ASCII (quoted-printable)>] > > > > On Wed, 17 Apr 2019 21:41:41 -0400, John Covici wrote: > > > > > > > > > Apr 17 18:39:55 ccs.covici.com systemd-coredump[5334]: Process > > > > > 5332 (umount.davfs) of user 0 dumped core. > > > > > Apr 17 18:39:55 ccs.covici.com systemd[1]: > > > > > [email protected]: Succeeded. > > > > > > > > > > I can't find that coredump, not sure if the process is allowed to > > > > > do it. > > > > > > > > From the systemd-coredump man page: > > > > > > > > By default, systemd-coredump will log the core dump including a > > > > backtrace if possible to the journal and store the core dump itself > > > > in an external file in /var/lib/systemd/coredump. > > > > > > > > You can change this in /etc/systemd/coredump.conf > > > > > > Thanks, I found it, but the backtrace has no symbols, even though I > > > have features set so that everything is compiled with symbols like > > > this: > > > FEATURES="${FEATURES} -stricter -distcc -ccache splitdebug buildpkg" > > > I wonder what is happening here? > > > > > > Strange thing si I have seen nothing on bgo for this problem. > > > > > > > I have the same problem on one of my machines. It segfaults somewhere > > in strcmp with avx2 according to a backtrace. > > Will try rebuilding my system libraries, since I changed lately from > > "march=native" to "march=x86-64 mtune=generic". I thought I rebuilt > > everything but there might be something missing for me. > > Anyway, for me as a workaround this works: fusermount -u MOUNTPOINT > > OK, I will try that and see if it works. > > Thanks. > I was debugging the issue today, and it's a bug in davfs2 as it seems... Line 151-153 in src/umount_davfs.c reads the following: char *pid = NULL; FILE *file = fopen(pidfile, "r"); if (!file || fscanf(file, "%a[0-9]", &pid) != 1 || !pid) { This is something I don't even understand what it is supposed to do, because there is so much wrong with it... %a would read a floating point (we all know, PID's are floating points...) The [0-9] is completely useless there.. The result is being saved in a char*... You could write it like this: char pid[32]; FILE *file = fopen(pidfile, "r"); if (!file || fscanf(file, "%s", pid) != 1) { This would fix the segmentation fault. And now the funny part: I wanted to report a bug, so I went to the website and wanted to see in the source code repository when this bug was introduced. However in the source code repository there is a correct implementation (similar to mine, actually more safe than mine) BUT any released version I tested from 1.4.7 until 1.5.5 all have this wrong implementation 1.4.7 was released in 2012, and the file src/umount_davfs.c wasn't changed since 2 years according to the repository browser. How the releases are correlating with the source code browser is at the moment beyound my understanding of this project. Anyone in contact with the development team of davfs2, who could shed some light on the situation? Cheers Andreas
