[gentoo-user] davfs2 suddenly not working properly
Hi. After my last world update, davfs2 is not working properly. I use it to mount my owncloud instance and it mounts fine, but the umount always segfaults and leaves the mount alone. Now, I can force to unmount by doing umount.davfs followed by the URL in question, but then the cache is never synced, so I just have to wait a while to make sure. The log says its seg faulting and claims that a core dump has occurred, but I can't find such a thing. Google and bgo reveal nothing. I am using the unstable gentoo and the glibc library was updated to2.29-r1 -- there is an r2, but I have not updated to it. Thanks in advance for any suggestions. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] davfs2 suddenly not working properly
On Tue, Apr 16, 2019 at 9:16 AM John Covici wrote: > Hi. After my last world update, davfs2 is not working properly. > > I use it to mount my owncloud instance and it mounts fine, but the > umount always segfaults and > leaves the mount alone. Now, I can force to unmount by doing > umount.davfs followed by the URL in question, but then the cache is > never synced, so I just have to wait a while to make sure. > You could run 'sync && umount.davfs' instead of waiting. > > The log says its seg faulting and claims that a core dump has > occurred, but I can't find such a thing. Google and bgo reveal > nothing. I am using the unstable gentoo and the glibc library was > updated to2.29-r1 -- there is an r2, but I have not updated to it. > > Can you paste the messages here? If it were me i'd just do these and try again after each step to see if any of them help - update glibc and reboot - try rebuilding util-linux and davfs2 - run 'strace umount ' Even though i don't understand a lot of the output, its possible to see libraries failing to load, or files unreadable etc
Re: [gentoo-user] davfs2 suddenly not working properly
On Mon, 15 Apr 2019 23:46:25 -0400, Adam Carter wrote: > > [1 ] > [2 ] > On Tue, Apr 16, 2019 at 9:16 AM John Covici wrote: > > Hi. After my last world update, davfs2 is not working properly. > > I use it to mount my owncloud instance and it mounts fine, but the > umount always segfaults and > leaves the mount alone. Now, I can force to unmount by doing > umount.davfs followed by the URL in question, but then the cache is > never synced, so I just have to wait a while to make sure. > > You could run 'sync && umount.davfs' instead of waiting. > > The log says its seg faulting and claims that a core dump has > occurred, but I can't find such a thing. Google and bgo reveal > nothing. I am using the unstable gentoo and the glibc library was > updated to2.29-r1 -- there is an r2, but I have not updated to it. > > Can you paste the messages here? > > If it were me i'd just do these and try again after each step to see if any > of them help > - update glibc and reboot > - try rebuilding util-linux and davfs2 > - run 'strace umount ' Even though i > don't understand a lot of the output, its possible to see libraries failing > to load, or files unreadable etc I did all the steps you suggested, except the strace, but no joy. I upgraded glibc, upgraded the kernel which I had to do anyway and rebuilt net-fs/davfs2 and rebooted. I did rebuild util-linux, but I did that before the upgrade, not sure if that would make a difference. the messages from the segfault are: Apr 17 18:39:55 ccs.covici.com kernel: umount.davfs[5332]: segfault at 45a0d000 ip 7f90082bfb96 sp 7ffcd47b49f8 error 4 in libc-2.29.so[7f9008242000+159000] Apr 17 18:39:55 ccs.covici.com kernel: Code: 0f 1f 40 00 66 0f ef c0 66 0f ef c9 66 0f ef d2 66 0f ef db 48 89 f8 48 89 f9 48 81 e1 ff 0f 00 00 48 81 f9 cf 0f 00 00 77 6a 0f 6f 20 66 0f 74 e0 66 0f d7 d4 85 d2 74 04 0f bc c2 c3 48 83 Apr 17 18:39:55 ccs.covici.com systemd[1]: Created slice system-systemd\x2dcoredump.slice. Apr 17 18:39:55 ccs.covici.com systemd[1]: Started Process Core Dump (PID 5333/UID 0). 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. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici wb2una cov...@ccs.covici.com
Re: [gentoo-user] davfs2 suddenly not working properly
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 -- Neil Bothwick Documentation: (n.) a novel sold with software, designed to entertain the operator during episodes of bugs or glitches. pgpollff2KEax.pgp Description: OpenPGP digital signature
Re: [gentoo-user] davfs2 suddenly not working properly
On Thu, 18 Apr 2019 03:20:25 -0400,
Neil Bothwick wrote:
>
> [1 ]
> 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.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
cov...@ccs.covici.com
Re: [gentoo-user] davfs2 suddenly not working properly
On Thu, 18 Apr 2019 10:14:13 -0400
John Covici wrote:
> On Thu, 18 Apr 2019 03:20:25 -0400,
> Neil Bothwick wrote:
> >
> > [1 ]
> > 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
Cheers
Andreas
Re: [gentoo-user] davfs2 suddenly not working properly
On Tue, 07 May 2019 01:58:25 -0400,
Andreas Fink wrote:
>
> On Thu, 18 Apr 2019 10:14:13 -0400
> John Covici wrote:
>
> > On Thu, 18 Apr 2019 03:20:25 -0400,
> > Neil Bothwick wrote:
> > >
> > > [1 ]
> > > 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.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
cov...@ccs.covici.com
Re: [gentoo-user] davfs2 suddenly not working properly
On Tue, 07 May 2019 01:58:25 -0400,
Andreas Fink wrote:
>
> On Thu, 18 Apr 2019 10:14:13 -0400
> John Covici wrote:
>
> > On Thu, 18 Apr 2019 03:20:25 -0400,
> > Neil Bothwick wrote:
> > >
> > > [1 ]
> > > 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
That seems to work, I hope it does a sync somewhere in there.
Thanks.
--
Your life is like a penny. You're going to lose it. The question is:
How do
you spend it?
John Covici wb2una
cov...@ccs.covici.com
Re: [gentoo-user] davfs2 suddenly not working properly
On Tue, 07 May 2019 02:25:13 -0400
John Covici wrote:
> On Tue, 07 May 2019 01:58:25 -0400,
> Andreas Fink wrote:
> >
> > On Thu, 18 Apr 2019 10:14:13 -0400
> > John Covici wrote:
> >
> > > On Thu, 18 Apr 2019 03:20:25 -0400,
> > > Neil Bothwick wrote:
> > > >
> > > > [1 ]
> > > > 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
