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:
>
>
> On Fri, 14 Mar 2003, Scott Gilbertson wrote:
>
> > The attached small C program causes my Xfbdev server to crash in CopyGC.
> > Usually it's a SIGSEGV, but sometimes its a SIGILL. When the program
> > starts, it shows a blank screen. Click mouse button 1 and it starts
> > animating some circles, and does so until you kill it (control-C or
> > whatever). On my embedded system, it crashes the X server in about 10
> > minutes. Using gdb, I've looked at the source and destination GC, including
> > all the function pointers. Everything looks fine -- no indication of what
> > made it crash.
> >
> > Running the same program on a desktop PC, it hasn't crashed yet, although I
> > haven't tried to run it for all that long.
> >
> > I'm wondering:
> > a) Is there any obvious should-not-do code in the attached program?
>
> Even a malicious app should not be able to crash the server.
>
> > b) Is high-volume XCreateGC/XCopyGC/XFreeGC (see below) considered normal?
>
> I'm sure there are other apps that do things like that. I think
> nearly every abuse has been done at one point or another.
>
> > c) Could the high volume be causing the problem?
>
> I still think it's likely to be a system memory problem or code generation
> problem.
>
> > d) Can anyone else replicate this crash?
>
> If I can remember I'll leave it running overnight on one of my machines
> tonight.
>
>
> Mark.
>
> >
> > My Xfbdev is version 4.3, but the same thing happens on 4.2.0. I've tried
> > compiling it with gcc 3.2.1 and 3.3 (not released yet), and both with and
> > without optimization. The one I'm running at the moment was compiled for
> > Intel 486.
> >
> > My system is an Arcom SBC-GX1, which uses a National Geode GX1 chip
> > (Pentium-compatible). It has 128 megs of RAM and no swap. At no time
> > during the test does the free RAM drop below 20 megs. It's obviously
> > conceivable that the problem is related to the non-Intel processor, but I
> > would have expected the symptoms to change with different optimizer settings
> > if that were the case. I suppose the kernel or video FB driver could also
> > be at fault.
> >
> > My linux is:
> > Linux version 2.4.18-rthal5 ([EMAIL PROTECTED]) (gcc version 3.2.1) #1 Wed
> > Dec 18 17:39:47 EST 2002
> >
> > History:
> > I've been trying to track down an Xfbdev crash when running a gcj-compiled
> > (Java) executable using the xlib peers. I noticed that the C xlib examples
> > I found don't do very many XCreateGC, XCopyGC and XFreeGC calls, whereas the
> > java library peers create a new GC for every repaint. The attached C
> > program creates a new GC every paint, just like the peers. Since it crashes
> > the server in the same manner as the Java program, it's not strictly a
> > problem with the Java compiler or libraries.
> >
> >
> >
>
>
_______________________________________________
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
