The server crash seems to be an incompatibility between Xfree86 and RTAI. With the RTAI real-time extension driver (which my main application requires) unloaded, I get the same result as you (ran for about 5 hours then crashed with "out of memory"). I was investigating the memory leak when I thought to look at your reply. Thanks for the specific code, which I have now inserted in the test program - new code attached.
With the RTAI module (rtai.o - see http://www.aero.polimi.it/~rtai/) loaded, the server crash still happens as before (segv in CopyGC about 10 minutes into the run), so it appears that either: a) there's an out-and-out bug in RTAI corrupting memory or something b) there's a sensitivity in Xfbdev or a frame-buffer driver, which RTAI brings out My tendency is to think 'b', because the crash happens in the same Xfbdev function regardless of how I build it or which version of XFree86 I use. If RTAI was, for example, trashing some Xfbdev code, you'd expect the crash to happen in different places with different builds and Xfree86 versions, because the memory addresses change. So my new question is, what is there about the X server that could be affected by the real-time extensions? I think the main thing rtai.o does is to hook all the interrupts, so that they can be prioritized and dispatched by RTAI. This way, the real-time interrupts and tasks are given high priority. It also sets things up so that none of the linux code ever does a hard interrupt disable, converting such requests to a "soft" disable, so that real-time interrupts can still get through. I would think the main effect of these things on a non-real-time program would be to alter its timing. It's also possible that the timers and associated interrupts are altered in some way when rtai.o is loaded, but I'm not sure about that. Are there critical operations in the X server which could be messed up by any of these things? BTW I'm posting a similar question on the RTAI mailing list. ----- Original Message ----- From: Network Administrator <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 17, 2003 9:22 AM Subject: Re: [XFree86] Attached C program causes Xfbdev 4.3.0 crash in CopyGC I let this app run until the OOM handler killed it. As is, this app has a memory leak. In your render loop you are not clearing out your event queue. Your XCopyArea is generating NoExpose events so eventually the client's event queue grows to the point where the kernel has to kill it. I don't think there's anything wrong with the server, but maybe if you exaust all your memory, which this app WILL eventually do, the kernel may start killing things indiscriminantly. In my case the kernel killed the app, not the server. There was a blurb about that in /var/log/messages. If you put: while(XPending(dpy)) XNextEvent(dpy, &report); in the render loop of this test app, it should keep the event queue clear. If that fixes the problem, it just sounds like you ran out of memory and the kernel killed the server. I wasn't seeing the server grow during this test. Mark On Fri, 14 Mar 2003, Mark Vojkovich wrote:
manyGC.c
Description: Binary data
