On 3/25/12 9:51 PM, Nehemiah I. Dacres wrote:
> you can be sure its not being killed by intercepting SIGTERM to print
> a debug message before exiting.Well, I tried that no msg. I also tried setting a signal handler for
every signal from 1 to 31 - none fired.
Then, I turned of fcntl(F_FULL_SYNC), and replaced it with
msync(MS_SYNC) just before every munmap, and the crash stopped
(execution time stayed exactly where it was using F_FULLFSYNC).
Finally, I changed MS_SYNC to MS_ASYNC, and the app still worked with an
execution time exactly as in the MS_SYNC case ?!?!?!
I'm testing every mmap/msync/munmap return code and asserting if not 0.
I logged every mmap and munmap to assure myself that in fact I was
properly unmapping the proper address/size pair. I even tried in a bogus
assert() to assure myself the asserts were working.
What I glean from all this is as follows:
- a program can write to files much faster than the file system can sync
it to disk (no surprise)
- the OS must assign the memory consumed in the Unified Buffer Cache to
the process consuming it (i.e. writing the files)
- when the combined memory consumption (ubc and heap) exceed a certain
size, the process gets clobbered - or perhaps if the ubc consumption
alone exceeds a threshold the process gets terminated. [I log UIKit
memory messages and have seen them in this same code under different
- probably the OS code that deals with a memory hog using large numbers
of ubc buffers is different from the code that detects heap based memory
hogs, and the way the process gets clobbered is just more opaque. This
is why I get no signal, there is no log message, lldb/gdb cannot detect
the termination, etc.
If I had the means to probe the ubc as to my consumption, even if was
crude, I'd have the means to throttle my usage to some "safe" value. As
it stands, with this being apparently so opaque, my only option is to
sync all the time (for a much poorer user experience).
Thus, any ideas on how I might uncover my actual UBC usage most welcome
(or uncovering how much is too much :-) )