httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "BOYA SUN" <boya....@case.edu>
Subject bugs/inappropriate coding practice discovered by interprocedural code analysis for version 2.2.8 of Apache
Date Wed, 14 May 2008 18:44:19 GMT
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@case.edu)
Ray-yaung Chang(ray-yaung.chang@case.edu)
Boya Sun(boya.sun@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@case.edu
2008-05-13
Mime
View raw message