Dear Apache Portable Runtime (APR) developers:
Thanks a lot for your quick and kind reply. Your feedback are really helpful
to us for improving the accuracy of our method.
For 1:
We agree with your reply that it should not be a bug.
For 2:
We are trying to understand this problem in the following way. In the file
"file_io/unix/open.c", since there exists the codes (line 166 to 180) which
have already set FD_CLOEXEC if APR_FOPEN_NOCLEANUP was not set, so the codes
(line 214 to 218) do not have bugs.
Filename: file_io/unix/open.c, Function: apr_file_open()
166 if (!(flag & APR_FILE_NOCLEANUP)) {
167 int flags;
168
169 if ((flags = fcntl(fd, F_GETFD)) == -1)
170 return errno;
171
172 flags |= FD_CLOEXEC;
173 if (fcntl(fd, F_SETFD, flags) == -1)
174 return errno;
175 }
.....
179 (*new)->flags = flag;
180 (*new)->filedes = fd;
.....
214 if (!(flag & APR_FILE_NOCLEANUP)) {
215 apr_pool_cleanup_register((*new)->pool, (void *)(*new),
216 apr_unix_file_cleanup,
217 apr_unix_child_file_cleanup);
218 }
For 3:
Besides the possible bug 3.1 we mentioned in the last email, we have found a
similar problem 3.2 as well.
According to the bug-fix pattern in the function "apr_file_mktemp()", we
think that APR may also set "flags |= FD_CLOEXEC" (line 279 to 290) under
the condition of "#ifndef HAVE_ACCEPT4" in the functions
"apr_os_sock_make()" and "apr_os_sock_make()".
**************************original bug-fix**********************************
Filename: file_io/unix/mktemp.c, Function: apr_file_mktemp()
176 apr_status_t apr_socket_accept(apr_socket_t **new, apr_socket_t *sock,
177 apr_pool_t *connection_context)
...
195 alloc_socket(new, connection_context);
....
276 (*new)->local_interface_unknown = 1;
277 }
278
279 + #ifndef HAVE_ACCEPT4
280 + {
281 + int flags;
282 +
283 + if ((flags = fcntl((*new)->socketdes, F_GETFD)) == -1)
284 + return errno;
285 +
286 + flags |= FD_CLOEXEC;
287 + if (fcntl((*new)->socketdes, F_SETFD, flags) == -1)
288 + return errno;
289 + }
290 + #endif
291
292 (*new)->inherit = 0;
**************************discovered possible new
bug(s)***********************
(3.1) Filename: network_io/unix/sockets.c, Function: apr_os_sock_make()
411 apr_status_t apr_os_sock_make(apr_socket_t **apr_sock,
412 apr_os_sock_info_t *os_sock_info,
413 apr_pool_t *cont)
414 {
415 alloc_socket(apr_sock, cont);
....
439 else {
440 (*apr_sock)->remote_addr_unknown = 1;
441 }
(///We think here may exist a potential bug///)
442
443 (*apr_sock)->inherit = 0;
(3.2) Filename: network_io/unix/sockets.c, Function: apr_os_sock_put ()
449 apr_status_t apr_os_sock_put(apr_socket_t **sock, apr_os_sock_t
*thesock,
450 apr_pool_t *cont)
451 {
452 /* XXX Bogus assumption that *sock points at anything legit */
453 if ((*sock) == NULL) {
454 alloc_socket(sock, cont);
455 /* XXX IPv6 figure out the family here! */
456 /* XXX figure out the actual socket type here */
457 /* *or* just decide that apr_os_sock_put() has to be told the
family and type */
458 set_socket_vars(*sock, APR_INET, SOCK_STREAM, 0);
459 (*sock)->timeout = -1;
460 }
461 (*sock)->local_port_unknown = (*sock)->local_interface_unknown = 1;
462 (*sock)->remote_addr_unknown = 1;
463 (*sock)->socketdes = *thesock;
(///We think here may exist a potential bug///)
464 return APR_SUCCESS;
465 }
In our research, we analyzed some of your fixed bugs to build up a bug
pattern database, and then tried to find out whether there are similar bugs
left in the codes. Since all of these possible bugs are found by a set of
automatic system, it is hard to say we have understood your codes
completely. This is the reason we just indicate where there may exist a bug
but not submit patches.
Thank you very much for your precious time!
Sincerely,
Gang Shu
Computer Science Division, EECS
513 Olin Building
Case Western Reserve University
10900 Euclid Avenue
Cleveland, OH 44106
Email: [email protected]
-----Original Message-----
From: Bojan Smojver [mailto:[email protected]]
Sent: Thursday, August 20, 2009 3:14 AM
To: Jack Andrews
Cc: Gang Shu; [email protected]
Subject: Re: Bugs discovered by a research group at CWRU (2)
On Thu, 2009-08-20 at 17:08 +1000, Jack Andrews wrote:
> i think he's asking us to confirm or deny patterns that he has
> found that could indicate another bug that has a similar
> fix to a bug that was fixed previously.
Yeah, something like that:
----------------------
It would be greatly 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.
----------------------
So, for 1, I'm saying most likely not a bug. For 2, I'm saying also most
likely not a bug (although I initially thought there may be a problem,
because I keep thinking of fork() when someone says exec()). For 3, I'm
too confused to respond.
The reason I asked for patches is that if there is potential bug, then
obviously there is a potential fix. Usually, it's a bit easier to read
what is being fixed by reading the actual fix.
--
Bojan
