[Mesa-dev] [PATCH 0/2] Simple Klocwork patches

[Eero Tamminen]

Hi,

On 08.02.2016 00:07, Matt Turner wrote:
> On Sun, Feb 7, 2016 at 1:37 PM, Juha-Pekka Heikkilä
> <juhapekka.heikkila at gmail.com> wrote:
>> I know there are lot of places where there is malloc unchecked still
>> -- and then there is ralloc which is a story of its own. Reason why I
>> think checking these would be remotely useful in windows only (or
>> other way around, not under linux kernel) is on Windows one can get
>> the null pointer from malloc. On Androids I think memory over
>> committing has always been enabled and on Linux I suspect I belong to
>> the minority who like to set ulimits for memory.
>>
>> I agree checking these mostly is quite useless but there are those
>> corners where it may suddenly become valuable. When process is running
>> and everything has settled it will be weird if hit any of these checks
>> but any code which is run when process is starting I notice is the
>> place where things will fail if they fail. This is of course just my
>> opinion about the value of these checks but I really dislike
>> possibility of segfault when it is coming from a library.
>>
>> I didn't quickly notice where _mesa_error() get more heap. Stack it of
>> course needs but when I did stress test these _mesa_error() did still
>> work. Cannot promise my test was 100% correct though, I think it was
>> over year ago when I was playing with it.
>
> There's no guarantee that fprintf() doesn't call malloc. In fact, glibc's does.

If one is just concerned about not calling something that may use 
malloc, the functions listed by "man 7 signal" as async-signal-safe are 
safe in that respect (one cannot use malloc within signal handler context).


> Adding these checks is really useless.

If one runs out of memory when overcommit is enabled, in theory about 
anything the program does, can cause it to use more memory.  Not just 
allocations.   E.g. running code for handling an error, may cause kernel 
to need to allocate space to page that code into RAM.  This can happen 
even if the isn't run for the first time, if kernel had dropped that 
page from RAM.


	- Eero

(Modern desktop systems don't work well without overcommit.  Having 
system with programs that have large number of threads or otherwise 
hardly used memory mapping, like is case e.g. on fork, could be in 
trouble, unless they have overtly large amounts of RAM.)