Hi all, My company has recently started evaluating GNet for some of our projects, and we've found a couple of bugs in the latest version of GNet. I'll describe them, plus our fixes, here for people to provide feedback: The first of these is a multi-threading issue in DNS resultion. From an offline discussion with Tim Muller, we think this may be related to a bug listed in Bugzilla (bug ID 305854), but I'm not completely positive that they are the same. The problem is that when starting an asynchronous DNS request, there is a race condition where some variables may not be set before they are used in the thread that issues the DNS request. A detailed explanation follows - all of the code described here is in inetaddr.c: gnet_inetaddr_new_async() creates a GInetAddrNewState structure, then passes this structure as an argument in the call to gnet_inetaddr_new_list_async(). However, the fields inside this structure are only initialized after the call to gnet_inetaddr_new_list_async(). On some Linux kernel versions, the thread created by gnet_inetaddr_new_list_async() executes before these values are set, and this thread uses these fields. Since one of the fields is a pointer to a callback function, it segfaults when it tries to cal the callback. I'm not sure if this is a problem with the latest (gthread) version, not setting these values may lead to strange behaviour in other circumstances as well. Ther simple fix for this is to initialize the fields in the structure before calling gnet_inetaddr_new_list_async(). One of the fields is actually initialized with a pointer to a structure created by gnet_inetaddr_new_list_async(), and so in our fix we have moved that initialization inside gnet_inetaddr_new_list_async(). The attached diffs show our fix to this problem. The second bug that we have found is related to the way that the HTTP code receives data under some circumstances (see file conn-http.c). When the content length is zero, gnet_conn_http_conn_recv_nonchunked_data() reads the data line-by-line. In cases where the HTTP content-length header is not included in the response, this can lead to a problem with requests for binary data, since any line-terminating characters that appear in the data are treated as the end of the request, which leads to requests getitng aberted early. We have found two cases where the content-length header is not used: streaming audio (e.g. Internet radio stations) and the Windows Media Connect media server in Windows XP. The fix for this seems prety simple: gnet_conn_http_conn_recv_nonchunked_data() should only read data line-by-line if we have received a content-length header and the content length is really zero (i.e. in the first line of the function, if (conn->content_length > 0) should be replaced with if ((!conn->got_content_length) || (conn->content_length > 0)). We have a tested patch for version 2.0.7 that fixes this problem. The main reason I'm not posting a fix for the latest version here is that I can't test it due to network connectivity issues at the moment. Regards, Steve Morris. (See attached file: inetaddr-diffs.txt) -- Steve Morris (steve_morris arcadyan com) 5F, No. 16, Ln. 77, Xing Ai Rd., Taipei 114, Taiwan, R.O.C. Tel: +886 2 8791 8500 x1264
Attachment:
inetaddr-diffs.txt
Description: Binary data