I'm doing a compiled application under Root, where I have to continuously show graphics (TGraph or TH1) in a canvas. It runs quite well. However, after around 1000 canvas updates, the graphs are not shown anymore and I get instead messages like this:
"CAUTION: tmpfile /tmp/nT8YuN_cint can't open
Error: could not create file /tmp/nT8YuN_cint"
This message is displayed still a few minutes (with different file names), then the whole application crushes with "segmentation fault".
I tried a lot to get around this, no success. Now I do need help. I can tell you that the problem seems to be related to the fact that the graphics update is done from a Thread (TTHread class).
The code is compiled under Scientific Linux.
Thanks for any hints.
Laudo.
Thanks for the reply. I did not think of lack of space, because the machine is brand new, so I have over 200Gb free space.
But you seem to consider that the space available to the /tmp directory could be limited. In this case, may I ask you how I can check how much space is available, how can I change this limit, or how can I flush it inside the code, so the failure will not happen ?
Laudo.
The shell ‘df’ will tell how disk space is left. A priori on a new machine this should indeed not be a problem. However usually the disk is separated in distinct partitions (for example / and /home) and the one where /tmp was put may have been undersized.
CINT does need to generate those files and hence the crash is to be expected (a priori as soon as those message appear, things started to stop working).
Another thing you can do is to ‘monitor’ the content of /tmp while you are running, by issuing command like ‘ls -lart’.
df -h shows me that I have over 200Gb free space, around 1Gb for tempfs.
du -sch /tmp shows 232K. I do have monitored /tmp while the program is running, and there seemed to be nothing happening. It rather looks like there is no “permission” to write anything into /tmp. Then I tried to run it as root but still the problem remains.
hope you can provide me other hints, I’m really stuck, and time is an issue…
[quote=“pcanal”]Hi Laudo,
The shell ‘df’ will tell how disk space is left. A priori on a new machine this should indeed not be a problem. However usually the disk is separated in distinct partitions (for example / and /home) and the one where /tmp was put may have been undersized.
CINT does need to generate those files and hence the crash is to be expected (a priori as soon as those message appear, things started to stop working).
Another thing you can do is to ‘monitor’ the content of /tmp while you are running, by issuing command like ‘ls -lart’.
What is the complete screen output if you do (on the shell prompt)
echo 'void script () { printf("we are fine\n"); }' > /tmp/script.C
root.exe -b -q -l /tmp/script.C
root.exe -b -q -l /tmp/script.C+
In one of your previous comments, you say that CINT does need to create the temporary files.
But I noticed that the the attempt to write in the /tmp directory only occurs after around 1000 canvas updates. How come the error does not show for a smaller number of updates?
I repeat that the updates are done from a Thread running with the application.
[quote] How come the error does not show for a smaller number of updates? [/quote]From the last set of diagnosis, we know that the problem is not really with /tmp and that the message is actually a red-herring and that the real cause is somewhere else.
[quote]I repeat that the updates are done from a Thread running with the application.[/quote]Humm … please note that neither CINT nor the GUI are thread safe and you should, as much as possible, access both from a single thread.
Can you run your example through valgrind?
If you send me a complete running example showing the problem I will investigate further.
I do need a thread, because the data I have to plot come from an USB interfaced device. Data is being generated in a detector, and the application has to be permanently aware of new events.[/quote]
[quote]Can you run your example through valgrind? [/quote] What is valgrind ? [quote]If you send me a complete running example showing the problem I will investigate further. [/quote] This is a bit difficult, since a running event requires data acquisition.
My feeling is that there may be some protection at the Scientific-Linux level, so that when an application tries to access the disk it is blocked. Could it be so? Could it be changed?
[quote]so that when an application tries to access the disk it is blocked. Could it be so? [/quote]I don’t think so.
For valgrind see valgrind.org
This is an excellent tool to discover memory leak and (more importantly in your case) memory usage problem.
[quote]I do need a thread[/quote]Fair enough. However you must pay carefully attention that only one thread access the GUI (and CINT) at the same time.
Most likely you have left for the week-end. Anyway I leave you a question for monday: could you tell what is the maximum rate of a canvas update? I mean, how fast can Root draw a canvas and be ready for the next one?
(*) I suppose it depends on the processor, but let us take a standard machine for the estimate.
In addition to the processor, it depends of the amount of point in your histogram/graph. An example of update can be found at $ROOTSYS/tutorials/hsimple.C (run with “root.exe -l -q hsimple.C+”).
On my machine, with that example I getting a bit more than 55 updates per second.
[quote]In addition to the processor, it depends of the amount of point in your histogram/graph. An example of update can be found at $ROOTSYS/tutorials/hsimple.C (run with “root.exe -l -q hsimple.C+”).
On my machine, with that example I getting a bit more than 55 updates per second.[/quote]
This corresponds roughly to what I get in my machine.
By the way, although I do not yet understand what was going wrong… I managed to solve the problem. I am doing myself the plots, I mean: I draw polylines in the Canvas, then I add the axis, the units, etc. After I did this, the application runs smoothly.