<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - System hang when use glTexImage3D to specify a 3D texture image" href="https://bugs.freedesktop.org/show_bug.cgi?id=104760#c15">Comment # 15</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - System hang when use glTexImage3D to specify a 3D texture image" href="https://bugs.freedesktop.org/show_bug.cgi?id=104760">bug 104760</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>I just ran this locally, and indeed got piles of oom-killer. My system survived - a couple programs got killed - and Mesa eventually returned GL_OUT_OF_MEMORY. I'm not sure what we can do about this, to be honest. It sounds like the 'system hang' is that the Linux OOM killer torches something critical...which would be a general Linux problem with being out of memory. Prior to the bisected patch, Mesa would allocate pages for the texture on the first access. Now, it allocates it on creation. This programs happens to allocate a texture, and never use it. But if you ever did use it, you'd suffer the same fate. I find it highly unlikely that any real world program would hit this case - if someone allocates a texture, they probably intend to use it. Chris, is there some reason that the kernel can't just...swap those pages out? Nothing is using them. Perhaps we should madvise them until first use or something? Or, should we avoid allocating huge things (above some threshold) up front? Or...really...the OOM killer sabotaging systems seems like a core Linux problem, and not anything we can do much about...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>