On Tue, 07 May 2019 02:25:13 -0400
John Covici <cov...@ccs.covici.com> wrote:
> On Tue, 07 May 2019 01:58:25 -0400,
> Andreas Fink wrote:
> >
> > On Thu, 18 Apr 2019 10:14:13 -0400
> > John Covici <cov...@ccs.covici.com> 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]:
> > > > > systemd-coredump@0-5333-0.service: 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
