Bug 81691 - assert in test-icetcp
Summary: assert in test-icetcp
Status: RESOLVED MOVED
Alias: None
Product: nice
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Olivier Crête
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-23 21:31 UTC by Olivier Crête
Modified: 2015-06-26 13:50 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
log with G_MESSAGES_DEBUG=all NICE_DEBUG=all (226.89 KB, text/plain)
2014-07-23 21:32 UTC, Olivier Crête
Details

Description Olivier Crête 2014-07-23 21:31:42 UTC
Asserts when running the test-icetcp sometimes.
Comment 1 Olivier Crête 2014-07-23 21:32:18 UTC
Created attachment 103368 [details]
log with G_MESSAGES_DEBUG=all NICE_DEBUG=all
Comment 2 Youness Alaoui 2014-07-24 04:08:13 UTC
Thanks for the log.
According to what I see in the log, there is no bug with ice-tcp, but the test seems to be a bit flawed.
The way the test works, it runs until it gets 4 components state set to READY, then it sends data, and runs the mainloop again until it receives the data.
What happens in your log is that the 4 components go to READY state, the mainloop quits, we send the data and run the mainloop waiting for the reception of data, at the same time, the UPnP port mapping gets answered, which adds new connchecks and the state goes back to CONNECTED, the state_changed callback will see that it received 4 component state changes to READY already so it will quit the mainloop which checks how many bytes were receives and asserts since the peer didn't have time yet to read the data.
I think a solution to fix the unit test is to do like I did in other unit tests, decrement the number of READY components when we detect a ready->connected transition, but also make sure we call g_main_loop_quit only once even if we do connected->ready->connected->ready to avoid triggering a quit too early.
Comment 3 Philip Withnall 2015-06-26 13:50:55 UTC
Migrated to Phabricator: http://phabricator.freedesktop.org/T102


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.