Menu
▾
▴
gnuplot-beta
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-02 11:00:56
|
On Fri, 1 Oct 2004, Ethan Merritt wrote: [...] > But a change to TERM_TABLE might resolve the more general > problem seen in vector.dem, that the sequence > set term push > set term <new> > set output > replot > set term pop > loses the original output setting. I don't think these two are actually much related to each other. The problem with the above sequence from vector.dem is mainly in the way 'set term push/pop' operate: they store the *command line* options of the terminal, but they don't (and can't) store its internal state. Which means that 'set term push' closes the terminal (e.g. post.trm will write out its epilogue), and 'set term pop' opens it again (so post.trm will output the prologue with the next plot). So even if we did keep the output file open by storing its handle across the push/pop interval, the contents of the file would probably be unusable afterwards. Not to mention what may happen if some smartass tries set term post set out 'my.ps' # plot something set term push set term post color set out 'my.ps' replot set term pop replot In the current state of things, I suspect the only choice would be to either declare 'set term push' an error if an output file is open, or make it imply a 'set out' to close the file. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-02 11:07:59
|
On Fri, 1 Oct 2004, Daniel J Sebald wrote: > No doubt there. What about this "pstricks". Way back, I saw that one > and thought to update the image drivers in there. Then looking at it, > it seemed so outdated that I wondered about its worth. I tried running > 'all.dem' under pstricks; that soon failed. I tried 'image.dem'; image > don't pass through of course but some other elements in the plots > failed. pstricks is falling behind a bit. Well, that's what happens if none of its users bothers to speak up or participate in the maintenance. I'm quite sure we have drivers that have accumulated even more dust than pstricks. Putting such bugs into the SF.net tracker as soon as any of us notices them might be a good idea. Even if only to serve as a list of "things to do on a boring rainy weekend". [...] > From my understanding, EPS supposedly only differs from PS by the > presence of the bounding box information. I was talking about epslatex vs. pslatex. Those two are almost completely independent of each other. -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
|
From: Daniel J S. <dan...@ie...> - 2004-10-02 17:47:04
|
Hans-Bernhard Broeker wrote: >On Fri, 1 Oct 2004, Daniel J Sebald wrote: > > > >>No doubt there. What about this "pstricks". Way back, I saw that one >>and thought to update the image drivers in there. Then looking at it, >>it seemed so outdated that I wondered about its worth. I tried running >>'all.dem' under pstricks; that soon failed. I tried 'image.dem'; image >>don't pass through of course but some other elements in the plots >>failed. pstricks is falling behind a bit. >> >> > >Well, that's what happens if none of its users bothers to speak up or >participate in the maintenance. I'm quite sure we have drivers that have >accumulated even more dust than pstricks. > I'm not a user of pstricks, so I'm not advocating its update. In fact, I'd be willing to let that one go. The reason is that I think the e/pslatex approach is much superior. There's the nice graphics features of PostScript combined with the font and math scripts of LaTeX. Now, I looked at pstricks.sty on the web and see that there is a 2004 copyright suggesting it has been updated recently. Yet, it still looks rather skimpy. Perhaps what could be done is a ./configure switch to leave pstricks out of the terminal list by default. It's capabilities probably match pre-4.0 and its use may be limited (could ask the LaTeX developers). It's just as well to leave it as is and if someone complains about lack of features see if something can be done. >> From my understanding, EPS supposedly only differs from PS by the >>presence of the bounding box information. >> >> > >I was talking about epslatex vs. pslatex. Those two are almost completely >independent of each other. > > Yes, I found that out. They should be made very similar. Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-10-03 00:16:59
Attachments:
gplt_x11_leak_2oct2004.patch
|
I discovered memory leak problems in gnuplot_x11 a few days ago and have
uncovered a couple things so far.
The first bug I have fixed with the attached patch. Please apply this
short patch to CVS immediately. The problem also exists in 4.0.0,
unfortunately, so perhaps it should be fixed there as well. It isn't a
severe leak. When a plot is deleted, the commands in the buffer are
cleared. However, the plot->commands array is also dynamic and I
overlooked freeing that when building the linked list. (So my bad.) In
the 16 window scheme previous, this was not a problem because the
pointer "plot" was not discarded. However, when removing the link from
the list, "plot" is discarded and hence a valid plot->commands array is
discarded. The memory usage grows at a noticeable rate when there are a
lot of commands in windows that are closed often, so likely not too
noticeable.
Now the second problem. I haven't solved this one yet and I may need
some help from Ethan. Here is what I am noticing in CVS and in 4.0.0 on
my machine. When I start up gnuplot and do a plot, say "plot x", and
then resize the window with the mouse or redisplay it in some way, the
memory usage climbs at an appreciable rate. However, creating another
X11 plot and resizing does not show this behavior. I eventually noticed
that there is one extra command in the plot buffer for only the very
first plot. In the case of "plot x" it is 223 commands for the first
plot, 222 thereafter; and here is how they differ:
QAAWLMVMVJQTWL...
QAAWLMVMVJTWLM...
There is an extra 'Q' or font command at the tenth spot. I did not go
any further investigating why this extra Q is there for the first plot.
Perhaps Ethan can help. Is it gnuplot that is putting in the extra
command? Is it a mouse feedback command?
In any case, the question is why is this causing memory to disappear so
quickly? Those two command strings in the first plot are "QD" and then
later "QF". It is the QF causing problems which is executed as:
switch (buffer[1]) {
case 'F':
/* Strip out just the font name */
c = &(buffer[strlen(buffer)-1]);
while (*c <= ' ') *c-- = '\0';
pr_font(&buffer[2]);
XSetFont(dpy,gc,font->fid);
break;
When I comment out the "XSetFont" function, the memory leak goes away.
So, upon redisplaying the plot, there is an XClearWindow(). Does there
also need to be something that frees the fonts in the X window? (I'm
just guessing.)
Dan
PS: There may be another potential minor leak, but I don't think it
happens by default. This bit of code:
case ' ': {
static int cmd_tried = 0;
static char *cmd = NULL;
static unsigned long newGnuplotXID = 0;
/* If the "-ctrlq" resource is set, ignore ' ' unless
control key is also pressed */
if (ctrlq && !(modifier_mask & Mod_Ctrl))
break;
if (!cmd_tried)
cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
/* overwrite gnuplotXID (re)set after x11.trm:X11_options() */
if (newGnuplotXID) gnuplotXID = newGnuplotXID;
if (cmd) system(cmd);
}
if (gnuplotXID) {
XMapRaised(dpy, gnuplotXID);
XSetInputFocus(dpy, gnuplotXID, 0 /*revert */ ,
CurrentTime);
XFlush(dpy);
}
return;
If successful "getMultiTab..." mallocs a command on the heap and returns
it. It is used by the above system command, but nowhere is that pointer
freed after its use. The variables are static, and "(!cmd_tried)" would
protect against getting the command a second time if only it were set to
1 after getting the command.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-03 18:50:07
|
On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote: > It is the QF causing problems which is executed as: > case 'F': > /* Strip out just the font name */ > c = &(buffer[strlen(buffer)-1]); > while (*c <= ' ') *c-- = '\0'; > pr_font(&buffer[2]); > XSetFont(dpy,gc,font->fid); > break; > > When I comment out the "XSetFont" function, the memory leak goes away. So are you saying this is a memory leak in your X-server? That's not really surprising, but it's not something we can fix. How are you testing for memory leaks? |
|
From: Daniel J S. <dan...@ie...> - 2004-10-03 19:47:08
|
Ethan Merritt wrote: >On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote: > > >>It is the QF causing problems which is executed as: >> case 'F': >> /* Strip out just the font name */ >> c = &(buffer[strlen(buffer)-1]); >> while (*c <= ' ') *c-- = '\0'; >> pr_font(&buffer[2]); >> XSetFont(dpy,gc,font->fid); >> break; >> >>When I comment out the "XSetFont" function, the memory leak goes away. >> >> > >So are you saying this is a memory leak in your X-server? >That's not really surprising, but it's not something we can fix. > >How are you testing for memory leaks? > I watch the processes, specifically the memory size parameter, as windows are open and closed. (My window manager has a convenient system monitor for watching memory... but "ps" will do too.) When a window is open, the memory size increases, naturally. But when the window is closed, the memory size doesn't necessarily have to drop back down to its previous value because sometimes the heap isn't cleared immediately. (Perhaps the kernel thinks the process will want the memory again.) However, if you plot the same exact plot, the memory should not grow any higher than the previous. In other words, keep plotting and closing the same plot; we shouldn't see memory keep on growing, just stay within some limit. Now, for the unsolved leak, just resizing the very first plot should keep making the memory for the process "gnuplot_x11" keep growing. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-03 22:18:11
|
On Sunday 03 October 2004 11:49 am, Ethan Merritt wrote:
> On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
> > It is the QF causing problems which is executed as:
> > case 'F':
> > /* Strip out just the font name */
> > c = &(buffer[strlen(buffer)-1]);
> > while (*c <= ' ') *c-- = '\0';
> > pr_font(&buffer[2]);
> > XSetFont(dpy,gc,font->fid);
> > break;
> >
> > When I comment out the "XSetFont" function, the memory leak goes away.
OK. I confirm the leak, although I don't see any processes other than
gnuplot_x11 itself being affected.
I thought I knew how x11 fonts worked, but clearly I don't.
Three observations. I can't really explain any of them, but I'd be interested
whether you see the same:
1) The biggie.
X11 font handling has broken badly sometime since I first wrote it.
I'm not at all sure when, and I don't know how much it has to do with
the problem you have identified. It seems broken in the V4.0.0
release version also. The upshot is that if you open new plot windows
with new fonts, then old windows do not keep their original fonts.
I can't figure out exactly whose font they get instead, but there
must be a bookkeeping error somewhere.
2) the above call to XSetFont() returns BadResource, which is strange
because clearly the call is actually working. Also strange because
that's not listed on the man page as a possible return code.
3) adding the following to the head of pr_font() seems to make the
leak go away for a single-window test case.
But what if another plot is using this font?????
On the other hand, see problem (1); this is already messed up.
--- gplt_x11.c.orig
+++ gplt_x11.c
@@ -5078,6 +5085,11 @@
if (!fontname)
fontname = FallbackFont;
+
+ /* EAM DEBUG!!!! Release current font, if any */
+ if (font)
+ XFreeFont(dpy, font);
+
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-10-03 19:03:46
|
On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
> PS: There may be another potential minor leak, but I don't think it
> happens by default. This bit of code:
> if (!cmd_tried)
> cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
> if (cmd) system(cmd);
That's part of something that Petr added in Dec 2003.
I don't understand what it's for, even after reading the code and
the comments.
(And what is a "multitab console" anyhow? I use KDE on all my
machines, but I have no idea what piece or feature of the KDE
desktop this code affects).
It does seem that the code above should be changed to
if (cmd) {
system(cmd);
free(cmd);
}
Petr?
|
|
From: Daniel J S. <dan...@ie...> - 2004-10-03 19:50:09
|
Ethan Merritt wrote:
>On Saturday 02 October 2004 05:43 pm, Daniel J Sebald wrote:
>
>
>
>>PS: There may be another potential minor leak, but I don't think it
>>happens by default. This bit of code:
>> if (!cmd_tried)
>> cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
>> if (cmd) system(cmd);
>>
>>
>
>That's part of something that Petr added in Dec 2003.
>I don't understand what it's for, even after reading the code and
>the comments.
>
>(And what is a "multitab console" anyhow? I use KDE on all my
>machines, but I have no idea what piece or feature of the KDE
>desktop this code affects).
>
>It does seem that the code above should be changed to
> if (cmd) {
> system(cmd);
> free(cmd);
> }
>
>
Or, if the code should just check for the command once, under the
assumption that if it tries again it'll just get the same thing, then:
if (!cmd_tried) {
cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
cmd_tried = 1; /* or TRUE, or something */
}
|
|
From: Petr M. <mi...@ph...> - 2004-10-04 06:42:17
|
> >That's part of something that Petr added in Dec 2003.
> >I don't understand what it's for, even after reading the code and
> >the comments.
> >
> >(And what is a "multitab console" anyhow? I use KDE on all my
> >machines, but I have no idea what piece or feature of the KDE
> >desktop this code affects).
Mozilla, Konqueror, Konsole can have several sessions open simultaneously as
"tabs" in one window. For KDE Konsole, a tab is one window shell or shell
session.
See gplt_x11.c:
static char*
getMultiTabConsoleSwitchCommand(unsigned long *newGnuplotXID)
which says:
* Currently implemented for:
* - KDE's Konsole.
...
/* now test for GNOME multitab console */
/* ... if somebody bothers to implement it ... */
...
What it does:
1. Konsole session 1: run gnuplot, "plot x"
2. Open/switch to another session
3. Hit "Space" in gnuplot's X11 => gnuplot sends focus to the correct
konsole and browses it to the appropriate session
I think that GNOME has also multitab consoles -- that could be useful if
someones adds the same functionality there.
> Or, if the code should just check for the command once, under the
> assumption that if it tries again it'll just get the same thing, then:
>
> if (!cmd_tried) {
> cmd = getMultiTabConsoleSwitchCommand(&newGnuplotXID);
> cmd_tried = 1; /* or TRUE, or something */
> }
That's the correct fix, I've just cvs'ed it.
Petr
|
|
From: Hans-Bernhard B. <br...@ph...> - 2004-10-03 00:37:27
|
On Sat, 2 Oct 2004, Harald Harders wrote: > The cause for introducing the new API routine was that it allows some > interesting things that were not possible with the standard routine: > > - The use is able to leave out the file extensions. > For the user the question is: Since epslatex generates two files, which > of these is the correct one? With the new routine it is possible to > give 'outfile.eps', 'outfile.tex', or 'outfile' as output filename. That sounds like a sensible reason, indeed. The difference between pslatex and epslatex about which of the two file names you have to specify, and which will be generated by the driver, has been a pain in the lower back to explain to people. > - The option fullheader made it necessary to use another file open > routine. The fullheader mode is ment for producing a stand alone > postscript or pdf output file that can be included by any application, > using TeX texts. I think you've lost me there. How exactly is this different from 'aux file' mode of pslatx, or the default mode of operation of the existing epslatex? > This is done by producing a full LaTeX file with the > given output file name and an additional eps file with a prefix before > the extension. This is done to prevent mixing up the gnuplot-produced > eps file without text information and the final ps or pdf file produced > by dvips or pdflatex. You say "_the_ final... file" here as if it was sure such a tex'ed version was pretty much guaranteed to be produced --- whereas in actuality, that's not really the original intended mode of usage of either of these drivers. They're (originally, at least) meant for inclusion into larger LaTeX documents, not for producing postscript figures by a detour through TeX. Actually, if this is the kind of usage you have in mind, you could just do pslatex without the auxfile option. > I think, the new set_output routine could also be interesting for other > terminals, escpecially these with binary output or with more than one > output file. We have binary output covered quite fine as it is. It's really only "split stream" drivers, i.e. only epslatex and "pslatex aux", where this would actually make a difference, I think. > > I have some questions about your new terminal entry. > > > > Right now it is permitted (though discouraged) to call > > 'set output' before calling 'set term'. Would we have to > > forbid this absolutely? > > Mmh, I think it is a design bug that 'set output' immediately opens an > output file before it knows for which terminal the file will be used. I don't quite agree that this should count as a bug. A file is a file. It's quite a simple thing, really. Drivers shouldn't need a written instruction or a diploma to handle one ;-) -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |
