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
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
