On Don, 2003-03-27 at 14:51, Chris Rankin wrote: > > Tracing this back further into the > _tnl_CreateContext() function, I discovered that: > > ctx->swtnl_context = tnl = (TNLcontext *) CALLOC( > sizeof(TNLcontext) ); > > is returning NULL too. In other words, there is not > enough dynamic memory left in a machine with 1 GB of > RAM and an extra 0.5 GB of swap to allocate > approximately 4K of data. None of the Mesa code > expects this allocation to fail because none of them > checks any of the GLBoolean return codes. > > As I mentioned before, this only happens when the hack > is launched from xscreensaver. One obvious thing that > could be consuming a lot of memory in this scenario is > storing the original contents of the screen for when > the screensaver ends, but I still wouldn't have > thought that a 1280x1024 screen with 16 bit colour > would have floored the allocator. > > Can anyone suggest anything else to try, please?
I'd try something like electric fence or MALLOC_CHECK_ to see if something bad is happening before. > Does XFree86 impose a limit on per-process virtual memory, > or something?? Even if it did, it couldn't impose anything on a client. -- Earthling Michel D�nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ------------------------------------------------------- This SF.net email is sponsored by: The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today! http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
