Created attachment 887149 [details] cimserver stderr Description of problem: cimserver sometimes outputs GLib-GObject-CRITICAL error messages. This seems to happen only when event to a subscribed indication happens. Version-Release number of selected component (if applicable): tog-pegasus-2.12.1-12.fc20.x86_64 How reproducible: Sometimes Steps to Reproduce: 1. run cimserver daemon=false forceProviderProcesses=false 2. subscribe for account deletion indication 3. remove an account Actual results: Sometimes, series of assertion failure messages are emitted to cimserver's stderr Expected results: No error output Additional info: It seems that the messages are come in series of either 8 or 14 messages (stripped the "(process:1368): GLib-GObject-CRITICAL **: " part for brevity): g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed [...later...] g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed
This doesn't seem to be issue in Pegasus, the messages come from provider, OpenLMI account in this case I assume.
Shifting to openlmi-account (and indication manager) owner.
Ah yeah, this is a common example of incomplete data received from libuser, usually happens as a some sort of race condition. Are you experiencing these messages under heavy load or is it really just a single account removal? Is there something bad in your passwd files?
(In reply to Tomáš Bžatek from comment #3) > Are you experiencing these messages under heavy load or is it really just a > single account removal? It's always just one account. Speaking of load, if that matters I did try scenario with 1000 subscriptions for the (single) event, but that did not seem to change amount of errors from CIMOM. > Is there something bad in your passwd files? Well, many UIDs have different numbers than their respective GIDs (e.g. "mail:x:8:12:..."), which can be annoying, but the files seem valid (I've checked them by hand).
> > Is there something bad in your passwd files? > > Well, many UIDs have different numbers than their respective GIDs (e.g. > "mail:x:8:12:..."), which can be annoying, but the files seem valid (I've > checked them by hand). For that matter, it's pretty much new installation from an official Fedora 20 ISO, so I guess it should not be that broken.
Could you please retest with nightly builds? There's a chance the issue might be gone as there were lots of fixes and development in between. https://fedorahosted.org/openlmi/wiki/NightlyBuilds
(In reply to Tomáš Bžatek from comment #6) > Could you please retest with nightly builds? There's a chance the issue > might be gone as there were lots of fixes and development in between. > > https://fedorahosted.org/openlmi/wiki/NightlyBuilds I think that results will be nearly same... Locking is still badly implemented in account provider.
(In reply to Alois Mahdal from comment #0) > Created attachment 887149 [details] > cimserver stderr > > Description of problem: > cimserver sometimes outputs GLib-GObject-CRITICAL error messages. This > seems to happen only when event to a subscribed indication happens. Is data read from shadow/passwd via libuser valid after GLIB assert messages? Valid means: no garbage in usernames, comments, uids... Garbage means: random ASCII characters. Non random ASCII characters.
(In reply to Tomáš Bžatek from comment #6) > Could you please retest with nightly builds? Sorry, still I get the errors: # rpm -q openlmi-providers openlmi-providers-0.4.2_241_ge46160a-5.fc21.x86_64 # rpm -q tog-pegasus tog-pegasus-2.12.1-12.fc20.x86_64 # cat cimserver.err | cut -d\ -f 4- | grep -v ^$ g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_long: assertion 'G_VALUE_HOLDS_LONG (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed g_value_array_get_nth: assertion 'value_array != NULL' failed g_value_get_string: assertion 'G_VALUE_HOLDS_STRING (value)' failed
(In reply to Alois Mahdal from comment #9) > (In reply to Tomáš Bžatek from comment #6) > > Could you please retest with nightly builds? > > Sorry, still I get the errors: Good. Big surprise...
(In reply to Robin Hack from comment #10) > (In reply to Alois Mahdal from comment #9) > > (In reply to Tomáš Bžatek from comment #6) > > > Could you please retest with nightly builds? > > > > Sorry, still I get the errors: > Good. Big surprise... https://bugzilla.redhat.com/show_bug.cgi?id=1061153 https://bugzilla.redhat.com/show_bug.cgi?id=1001490 https://fedorahosted.org/openlmi/ticket/81
(In reply to Robin Hack from comment #11) > https://bugzilla.redhat.com/show_bug.cgi?id=1061153 This one has been already pushed upstream and is included in nightly builds that Alois tested. > https://bugzilla.redhat.com/show_bug.cgi?id=1001490 > > https://fedorahosted.org/openlmi/ticket/81 I don't think this will help much as this bugreport is not about concurrent access.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.