qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Fail] tests/test-util-filemonitor fails


From: Miguel Arruga Vivas
Subject: Re: [Qemu-devel] [Fail] tests/test-util-filemonitor fails
Date: Mon, 4 Nov 2019 20:35:23 +0100

Hi Daniel,

I've been trying to open a bug in launchpad about exactly this, but it
always raises an error when trying to log in.  Then I found this
thread diving into the archives, so I'll try to kindly ask here about
it.

Daniel P. Berrangé <address@hidden> wrote:
> On Fri, Aug 09, 2019 at 08:06:09AM +0800, Wei Yang wrote:
> > On Thu, Aug 08, 2019 at 10:22:13AM +0100, Daniel P. Berrangé
> > wrote:  
> > >On Thu, Aug 08, 2019 at 04:46:53PM +0800, Wei Yang wrote:  
> > >> On Thu, Aug 08, 2019 at 09:02:29AM +0100, Daniel P. Berrangé
> > >> wrote:  
> > >> >On Thu, Aug 08, 2019 at 10:07:23AM +0800, Wei Yang wrote:  
> > >> >> Current qemu fails tests/test-util-filemonitor.  
> > >> >
> > >> >You'll need to provide more info. The test works for me and
> > >> >passes in all the QEMU CI environments.
> > >> >  
> > >> 
> > >> The error message from my side is:
> > >> 
> > >> /util/filemonitor: Expected watch id 200000000 but got 100000000
> > >> **
> > >> ERROR:tests/test-util-filemonitor.c:665:test_file_monitor_events:
> > >> assertion failed: (err == 0)
> > >> 
> > >> What else you'd prefer to have?  
> > >
> > >Can you set the  "FILEMONITOR_DEBUG=1" env variable before running
> > >the test - it will print out lots more info
> > >  
> > 
> > Here is the output with more info.
> > 
> >     $ FILEMONITOR_DEBUG=1
> > QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
> > tests/test-util-filemonitor  
> 
> >     Rmdir /tmp/test-util-filemonitor-151B6Z/fish
> >     Event id=200000000 event=4 file=
> >     Expected watch id 200000000 but got 100000000
> >     **  
> 
> Ok, so the kernel is sending the events in an unexpected order

I've been reading about the issue and as far as I understand the inotify
man-page[http://man7.org/linux/man-pages/man7/inotify.7.html], section
"Dealing with rename() events", points out that the order nor the
atomicity of the concurrent events is something that should be relied
on.
 
> >     ERROR:tests/test-util-filemonitor.c:665:test_file_monitor_events:
> > assertion failed: (err == 0) Aborted (core dumped)
> > 
> >   
> > >Also what operating system are you using, and what kernel version

We have hit this error on GNU Guix master
[http://issues.guix.gnu.org/issue/37860]. I'm using linux-libre 5.3.4
on x86_64.  It does not seem to be something deterministic, but I just
commented out the test the fifth time I've hit the same error.

Is there any way to change the test to not rely on the ordering of the
events from different views of the same fs action?

Best regards,
Miguel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]