apr-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 41119] - apr_pool_cleanup_for_exec must discard I/O buffers
Date Wed, 18 Apr 2007 06:15:28 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41119>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41119





------- Additional Comments From bojan@rexursive.com  2007-04-17 23:15 -------
Yes, I can confirm this. This is what the _child_ process does:

------------------------------------------
(gdb) bt
#0  apr_unix_file_cleanup (thefile=0x8aa40d8) at file_io/unix/open.c:32
#1  0x009910ee in run_child_cleanups (cref=0x8aa40b0)
    at memory/unix/apr_pools.c:2090
#2  0x00991112 in cleanup_pool_for_exec (p=0x8aa40a0)
    at memory/unix/apr_pools.c:2097
#3  0x00991128 in cleanup_pool_for_exec (p=0x8aa40a0)
    at memory/unix/apr_pools.c:2100
#4  0x00991159 in apr_pool_cleanup_for_exec () at memory/unix/apr_pools.c:2115
#5  0x0099cf43 in apr_proc_create (new=0x8aa5148, 
    progname=0x8048919 "/bin/ls", args=0xbfc7944c, env=0xbfc793ec, 
    attr=0x8aa5158, pool=0x8aa40a0) at threadproc/unix/proc.c:403
#6  0x080487d1 in main () at test.c:32
------------------------------------------

With this in *file:

------------------------------------------
(gdb) p *file
$9 = {pool = 0x8aa40a0, filedes = 7, fname = 0x8aa4128 "/tmp/testfile", 
  flags = 230, eof_hit = 0, is_pipe = 0, timeout = -1, buffered = 1, 
  blocking = BLK_ON, ungetchar = -1, buffer = 0x8aa4138 "0123456789", 
  bufpos = 10, bufsize = 4096, dataRead = 0, direction = 1, filePtr = 0, 
  thlock = 0x0}
------------------------------------------

That's what writes the first 10 bytes from the example. Of course, the same 10
bytes are in the parent's buffer. Later on the parent comes to
apr_unix_file_cleanup() too and flushes out 20 bytes (another 10 were written in
the meantime), giving the total of 30.

As it stands, the cleanup (when it gets called) has no idea if it should flush
the stuff out or not.

One solution may be to create linked list of opened files and put every file in
it on apr_file_open(). The files would also have to unlinked on
apr_file_close(), of course.

This list could then be traversed in apr_pool_cleanup_for_exec() and all
file->buffered flags could be set to zero before running the actual cleanup.
Then the buffer wouldn't get flushed. Yeah, pretty corny, I know...

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@apr.apache.org
For additional commands, e-mail: bugs-help@apr.apache.org


Mime
View raw message