Bug 329802 - kcoreaddons-kdirwatch_fam_unittest fails when using gamin
Summary: kcoreaddons-kdirwatch_fam_unittest fails when using gamin
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kcoreaddons
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Michael Pyne
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-01-10 10:39 UTC by Michael Palimaka
Modified: 2014-06-06 15:33 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
LastTest.log (71.62 KB, text/plain)
2014-01-10 10:39 UTC, Michael Palimaka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Palimaka 2014-01-10 10:39:40 UTC
Created attachment 84549 [details]
LastTest.log

The following tests FAILED:
         13 - kcoreaddons-kdirwatch_fam_unittest (Failed)

FAIL!  : KDirWatch_UnitTest::testDeleteAndRecreateFile() 'waitForOneSignal(watch, SIGNAL(dirty(QString)), file1)' returned FALSE. ()
   Loc: [/home/michael/dev/kde/kcoreaddons/autotests/kdirwatch_unittest.cpp(487)]
Comment 1 Matthew Dawson 2014-05-28 04:23:22 UTC
I've taken an initial look into this issue, and I've so far found two issues:
1) KDirWatch has a race condition when using gamin.  After setting up the watch, the test proceeds to quickly delete/recreate the file.  But gamin doesn't have the inotify watch in place yet, so the server never even sees it.  Adding an artificial delay between the KDirWatch setup and file manipulation (I've used 500 ms) causes gamin to get the watches in place, which then allows the test to continue.
2) Using the FAM backend with gamin causes the deleted/created signals to be emitted, not the dirty signal.  Forcing the Inotify branch to be taken in the test allows the test to continue successfully.  I assume that branch is the preferred case?

Anyways, I'll see about whipping up a patch that fixes 1) and 2).  I'm not sure how 1) should be handled yet, as I'm not sure what allows the race.  Does anyone have any ideas?
Comment 2 Matthew Dawson 2014-06-06 15:33:59 UTC
Git commit d56f01760138fd8cd2c2a4e09916b65c31891065 by Matthew Dawson.
Committed on 04/06/2014 at 16:44.
Pushed by mdawson into branch 'master'.

Fix KDirWatch to act more reliably against various backends.

 - When KDirWatch used a FAM backend, it wouldn't actually wait for the
necessary watches to be put in place before returning, allowing for a race
where an application may think a watch is in place when it really isn't.
This was easily seen using gamin and running the testDeleteAndRecreateFile
test.  Fix by delaying useFAM until the watch is in place by waiting until
the EndExist FAM event is received.  This adds ~100-200ms per watch with
gamin.
 - When a file is deleted and recreated, and scanEntry detects it, the dirty
signal would be emitted.  Fix to emit a deleted + created signal, as expected.
 - When a deleted signal was requested, other signals were dropped.  Due to
the above point, this would stop the created signal from being emitted.  Now,
all signals are emitted, even when a delete is detected.
 - When watching recreated files, the created signal could get lost as there
was a race between when the created signal would be generated and its signal
spy would be created.  Fix by making sure the spy is created before the signal
could be emitted.
 - Make sure the created signal isn't emitted twice with both FAM and the
polling timer.  This occurs as FAM doesn't fix up the fact the entry has been
created, and the poller thus assumes it needs to notify the world.  Fix by
having FAM not emit the event in this case.
REVIEW: 118458

M  +48   -25   autotests/kdirwatch_unittest.cpp
M  +34   -17   src/lib/io/kdirwatch.cpp
M  +1    -0    src/lib/io/kdirwatch_p.h

http://commits.kde.org/kcoreaddons/d56f01760138fd8cd2c2a4e09916b65c31891065