X-win problems

[devgoswami]

I have a realtime X-win ( based on Xt+Xm kit)
display code , which produces 24 bit RGB colour or grey coded image display.
the Image displays start when a external process
provides the trigger and the data.
as such the display works automatically, the image display restarts on its own when the next trigger occurs.

the problem is after a few repitations (6/7/8..even 12 ) the above program traps out with a message
"X server- Error ???!! , process quota exceeded"

I have twiked around with the sysgen Pql, and system wide process parameters, and also tried loading the X-server with higher process quota limits. also tried around increasing the User
process quota in UAF as much as possible.
But all have not worked .

Anybody help?

M/c : Alpha - 500 Mhz, OVMS 6.2
DS - 25 1000 Mhz OVMS 7.3

[Peter Quodling]

The fact that it fails after several interations, of a particular program, also points to a memory leak. If so, any increase in quota is likely to only be a stopgap... I would check on patches back for 6.2, if you can get them still... (or upgrade).

Do you have access to the source?
Are you familiar with the Debugger, Heap analyzer and related tools?

Regards

Peter Q

[devgoswami]

Thanks for ur idea, I have the source code as me +team is the design and developement team.

i have tried out the debugger, but as the code entres the Xserver code area, the debug fails to provide the right info.

code walk thru done several times.

i use the Xputimage call to draw the images to the screen ( XT output).

does such a call unwind the stack on its own?

[Willem Grooters]

A general question:
Is the XServer software build to accommodate DEBUG (compile and link)? If not, the debugger won't be of help. If you have the code and build commands, rebuildt that part as well. If the code is in a shared library, be sure to specify this by a logical. When building and runnning, this ogical should refer the debug version - which does not have to be installed. For "normal" use, refer to the "official" version.

Then on your program - just a hints.
Each time the image display restarts on its own, it doesn't mean allocated memory is automatically freed. It will when the executable actually stops, is removed from memory and restarted, but when the image is kept in memory, it might well be the pages are kept allocated - causing your problem.
If the image display code is threaded, thread-local allocations will be charged against the process. If "restart of image display" means "starting another thread" you will consume memory out the limits.

Willem