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: gang.shu@case.edu
-----Original Message-----
From: Bojan Smojver [mailto:bojan@rexursive.com]
Sent: Thursday, August 20, 2009 3:14 AM
To: Jack Andrews
Cc: Gang Shu; dev@apr.apache.org
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