> >>> this reminds me that I've always been wondering about checks for > >>> allocation > >>> failure in WebCore (versus concerns about leaks). A plain call to new may > >>> throw an std::bad_alloc exception. If this is not considered, it may > >>> leave > >>> objects in an invalid state, even when using objects such as RefPtr to > >>> wrap > >>> arround allocations. I don't remember any specific place in the WebCore > >>> code > >>> where it would be a problem, I just don't remember seeing any code that > >>> deals with allocation failures. Is this a design choice somehow? If so, > >>> is > >>> there some online documentation/discussion about it? (Tried to google it > >>> but > >>> found nothing...) > >> > >> Failed allocations in WebKit call CRASH(). This prevents us from > >> ending up in an inconsistent state. > > > > Ok, but WebKit is used on devices where allocation failure is somewhat of a > > realistic possibility, no? Wouldn't it be desirable to handle such a > > situation gracefully? (I.e. display of an error message when trying to open > > one more tab rather than crashing the entire browser, for example.) > > Hopefully I am not missing something obvious. > > Dunno. The crash-on-allocation failure assumption is baked into lots > of lines of code. > > We do have a tryFastMalloc() path that returns NULL on allocation > failure instead of crashing. It's used in some pieces of code that are > carefully written to handle an allocation failure gracefully. > However, this is rare. > > In general it's very difficult to recover from an allocation failure in > an arbitrary piece of code with an arbitrary callstack. > > - James > ( hotmail is still having all kinds of problems, doesn't seem to like text or a modem connection, sorry for eidting slop ). I guess this relates to many earlier comments including that issue with the linker reporting a memory problem LOL. I'm just thinking out loud since no one on thread seems to have a lot of conviction so far. You could probably make a list of reasons why an allocation could fail: 1) the app is shutting down or OS is shutting down, 2) what you are trying todo is too big for the platform, 3) someone else has the resources you need for a tolerable or intolerable time, 4) you have bad data and calculated a size based on absurd numbers. 5) Algorithm failure, you have reasonable data but either code or algorirthm has a bug or impractical way of handling the data. Hopefully, you aren't just allocating memory on the spur of the moment," oh look I need more memory how about that," and could maybe even consider planning ahead. Presumably this helps validate your data, or at least sanity check it, maybe if you have 1<<30( hotmail somtimes tries to interpret gt, I mean of course 2^30 LOL if the shift operator got mangled ) and 1<<30 they really are not the width and height of an image or one you could practically show on the platform. I guess first it would help to make sure the platform API's give you abilities to determine what makes sense for the platform and some introspective API gave you some ability to understand who has what and why. Then more use of strategy type classes or planners could let you estimate memory needs and even allocate things together to improve coherence. It can be hard to clean up a partially created thing like a tab but if you group the memory allocations at a logical unit of some kind it would be a lot easier to just give up without trying. It is probably possible to warn the user too, " you have too much open" just as some browsers give the " a script is causing your computer to run slowly" message. While this is a bit grandiose I'm just trying to focus conversation and relate it to my fixation on memory coherence and resource usage.
> > Adam _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
