After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 693435 - eds test: create-remove-stores fails sporadically
eds test: create-remove-stores fails sporadically
Status: RESOLVED OBSOLETE
Product: folks
Classification: Platform
Component: e-d-s backend
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2013-02-08 17:30 UTC by Travis Reitter
Modified: 2018-09-21 16:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix the test by ensuring our sources are declared as enabled (as e-d-s does itself) (1.77 KB, patch)
2013-02-08 17:37 UTC, Travis Reitter
committed Details | Review
Test failure backtrace (2.43 KB, text/html)
2013-02-08 22:02 UTC, Travis Reitter
  Details
Test failure backtrace (4.93 KB, text/plain)
2013-02-08 23:50 UTC, Travis Reitter
  Details

Description Travis Reitter 2013-02-08 17:30:29 UTC
It's not clear exactly why, but the eds test create-remove-stores fails about 15% when run through gdb manually. It fails 100% of the time during a regular "make check" for at least all of eds.
Comment 1 Travis Reitter 2013-02-08 17:37:34 UTC
Created attachment 235528 [details] [review]
Fix the test by ensuring our sources are declared as enabled (as e-d-s does itself)

Patch from branch:

http://cgit.collabora.com/git/user/treitter/folks.git/log/?h=bgo693435-fix-create-remove-stores

(If this commit appears, just ignore it; I've removed it locally: "CUT -- temporarily disable flakey telepathy test")
Comment 2 Travis Reitter 2013-02-08 18:01:02 UTC
Hrm, I have managed to reproduce the problem a couple times even with this patch. But it still significantly reduces its frequency (again, for no apparent reason). So it's still worth applying.

I think there's something race going on on the EDS side that should be fixed (if it's invalid to exclude an Enabled line we should get an error earlier anyhow).

CC'ing Matthew in case he's got any insight. Here's the relevant ESource setup function:

http://git.gnome.org/browse/folks/tree/tests/lib/eds/backend.vala#n147 (this is before the patch has been applied as of this writing)
Comment 3 Matthew Barnes 2013-02-08 19:43:51 UTC
Exactly where is the test failing?

Is there a GError / warning message, or just an assertion tripping?
Comment 4 Travis Reitter 2013-02-08 22:02:59 UTC
Created attachment 235549 [details]
Test failure backtrace

Sorry, I thought I included this originally.

Anything else I can provide, Matthew?
Comment 5 Travis Reitter 2013-02-08 23:50:10 UTC
Created attachment 235559 [details]
Test failure backtrace

Sorry, not sure what happened that I ended up with broken HTML. Here's the actual backtrace.
Comment 6 Matthew Barnes 2013-02-09 00:21:08 UTC
That looks pretty deep in GDBus code.  An internal hash table lookup in GDBusObjectManagerClient is coming up empty for some reason.

The only removals on that hash table are in on_notify_g_name_owner() and further down in the same function where the warning is being issued.  Maybe it's being called twice for the same object path?

Nothing really E-D-S specific about any of this that I can see.
Comment 7 Philip Withnall 2013-02-10 23:50:41 UTC
Review of attachment 235528 [details] [review]:

++
Comment 8 Travis Reitter 2013-02-11 04:22:26 UTC
Comment on attachment 235528 [details] [review]
Fix the test by ensuring our sources are declared as enabled (as e-d-s does itself)

Applied - I'm leaving this bug open because it doesn't seem to be 100% fixed by this patch.
Comment 9 GNOME Infrastructure Team 2018-09-21 16:00:37 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/52.