boya.sun at case
May 14, 2008, 11:44 AM
Post #1 of 11
(317 views)
Permalink
|
|
bugs/inappropriate coding practice discovered by interprocedural code analysis for version 2.2.8 of Apache
|
|
Dear Apache-HTTPD developers,
I am a Ph.D student in the Software Engineering Research Group of EECS department in Case Western Reserve University, under the instruction of Prof. Andy Podgurski. In our very recent research, we applied inter-procedural code analysis and data mining technique on the version 2.2.8 of Apache project, and we have found 6 potential bugs, as indicated at the end of this email. The reason why we did not submit these bugs to the bug tracking system is that these potential bugs have not triggered any failure, and we cannot be sure whether these potential bugs are real bugs or just bad coding practice. We hope that these potential bugs can help you recognize some real bugs or inappropriate coding practice. It would also be greately appreciated if you can reply to this email after you have gone over the bugs and tell us whether you have confirmed any of them, since these information are really valuable for us for testing our current method.
The 6 bugs can be categorized into the following 2 groups:
Category-1: missing of a check of the return value of a function
A function may return an error code such as 0, -1 or NULL to indicate that an error occured inside of a function. We've found several potential bugs where a check of the return value is likely to be missing for certain functions.
Category-2: missing of a function call
This normally happens when a function call is missing in a set of function calls that always need to be invoked together, for example, malloc() and free().
The detailed information of each potential bug is as followed:
Category-1 or 2
File Name-the file where the bug occurs
Function Name-the function where the bug occurs
Buggy Code-exact line numbers of the buggy code
Description-description of the bug
Some of the potential bugs are inter-procedural, which cross many functions. These potential bugs are normally hard to be discovered by manual effort, and if they are real bugs, it should be valuable to developers since they are hard to be recognized. Note that for interprocedural potential bugs, there are several code segments involved. The info of some code segment is titled "Code" instead of "Buggy Code". This indicates that the code is not buggy, but is the inter-procedural environment of the real location of the bug. Some of the code segments are titled "Correct Code" to show an example of the correct coding practice.
Our previous work with intra-procedural analysis, which is mainly implemented by Ray-yaung Chang, are published in the following two papers:
[1] R. Chang, A. Podgurski, J. Yang,ˇ°Finding WhatˇŻs Not There: A New Approach to Revealing Neglected Conditions in Softwareˇ±, Proceedings of the 2007 International Symposium on Software Testing and Analysis, London, UK, July 2007, pp. 163-173.(Best Paper Reward)
[2] R. Chang, A. Podgurski, J. Yang, "Discovering Neglected Conditions in Software by Mining Dependence Graphs,", IEEE Transactions on Software Engineering, 14 Apr 2008 (preprint), IEEE Computer Society, http://doi.ieeecomputersociety.org/10.1109/TSE.2008.24.
If you have any further informations, please contact any of us:
Andy Podgurski(andy[at]case.edu)
Ray-yaung Chang(ray-yaung.chang[at]case.edu)
Boya Sun(boya.sun[at]case.edu)
Thanks!
Boya
------------------------------------------------------------------------------------------------------------------------------------------------
BUG#1
Category: 1
File Name: /httpd-2.2.8/support/ab.c
Function Name: open_postfile()
Buggy Code:
1901: apr_file_info_get(&finfo, APR_FINFO_NORM, postfd);
1902: postlen = (apr_size_t)finfo.size;
Description: An error might occur if the output of the function apr_file_info_get() is not APR_SUCCESS. The above code does not check the return value of the function.
=====================================================================
BUG#2
Category: 1
File Name: / httpd-2.2.8/srclib/apr/file_io/unix/seek.c
Function Name: apr_file_seek()
Correct Code:
126: apr_status_t rv = apr_file_flush_locked(thefile);
127: if (rv != APR_SUCCESS)
128: return rv;
File Name: /httpd-2.2.8/srclib/apr/file_io/unix/readwrite.c
Function Name: apr_file_flush()
Code:
330: APR_DECLARE(apr_status_t) apr_file_flush(apr_file_t *thefile)
ˇˇ
336: rv = apr_file_flush_locked(thefile);
ˇˇ
342: return rv;
File Name: / httpd-2.2.8/server/log.c
Function Name: As follows
Buggy Code:
229: apr_file_flush(ˇ); // file:/server/log.c Function Name: ap_replace_stderr_log()
424: apr_file_flush(ˇ); // file:/server/log.c Function Name: ap_open_logs()
683: apr_file_flush(ˇ); // file:/server/log.c Function Name: log_error_core()
901: apr_file_flush(ˇ); // file:/src/mod_cgi.c Function Name: cgi_handler()
123: apr_file_flush(ˇ); // file:/src/open.c Function Name: apr_file_close()
Description: As shown in the first code fragment (apr_file_seek()), the output of apr_file_flush_locked() should be checked to determine if it is APR_SUCESS. By inspecting the source code of apr_file_flush(), we infer that the output of apr_file_flush() should be checked to determine if it is APR_SUCCESS also. However, the output of apr_file_flush() is not checked in the third code fragment.
=====================================================================
BUG#3
Category: 1
File Name: /httpd-2.2.8/support/htcacheclean.c
Function Name: process_dir()
Buggy Code:
534: apr_file_read_full(fd, &expires, len, &len);
Description: We found a rule requiring checking if the output of apr_file_read_full() is APR_SUCCESS. However, the above code ignores this check.
=====================================================================
BUG#4
Category: 2
File Name: /httpd-2.2.8/modules/filters/mod_include.c
Function Name: handle_include
Buggy Code
1714: else {
1715: rr = ap_sub_req_lookup_uri(parsed_string, r, f->next);
1716: }
Description: We found a potential rule requiring that the ap_destroy_sub_req() be executed to release the object returned by ap_sub_req_lookup_uri(). However, ap_destroy_sub_req() is not called in the above code.
=====================================================================
BUG#5
Category: 2
File Name: /httpd-2.2.8/modules/http/http_request.c
Function Name: ap_internal_fast_redirect()
Buggy Code:
449: ap_remove_output_filter(r->output_filters);
450: r->output_filters = r->output_filters->next;
451: }
Description: We found a potential rule requiring that ap_pass_brigade() be called after the execution of ap_remove_output_filter(). However, the above code does not follow this potential rule.
=====================================================================
BUG#6
Category: 1
File Name: /httpd-2.2.8/srclib/srclib/apr-util/xml/expat/lib/xmlparse.c
Function Name: doProlog()
Buggy Code:
2670: ENTITY *entity = (ENTITY *)lookup(&dtd.paramEntities,
2671: externalSubsetName,
2672: 0);
2673: if (!externalEntityRefHandler(externalEntityRefHandlerArg,
2674: 0,
2675: entity->base,
2676: entity->systemId,
2677: entity->publicId))
Description: The function lookup() might return NULL. In the above code, the fields of the variable entity, returned by look(), are accessed without checking if it is NULL.
BOYA SUN
Computer Science Division
Electrical Engineering & Computer Science Department
513 Olin Building
Case Western Reserve University
10900 Euclid Avenue
Clevelnd, OH 44106
boya.sun[at]case.edu
2008-05-13
|
