|Summary:||assert in test-icetcp|
|Product:||nice||Reporter:||Olivier Crête <olivier.crete>|
|Component:||General||Assignee:||Olivier Crête <olivier.crete>|
|Status:||RESOLVED MOVED||QA Contact:|
|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] 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.