Bug 81691

Summary: assert in test-icetcp
Product: nice Reporter: Olivier Crête <olivier.crete>
Component: GeneralAssignee: Olivier Crête <olivier.crete>
Status: RESOLVED MOVED QA Contact:
Severity: normal    
Priority: medium CC: gnome, kakaroto
Version: unspecified   
Hardware: Other   
OS: All   
i915 platform: i915 features:
Attachments: log with G_MESSAGES_DEBUG=all NICE_DEBUG=all

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]
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.