Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2007-03-09 02:27:14
|
Hello, I've been calling gnuplot from my program, gretl, to generate graphs, for quite some time now. Since I require that gnuplot be able to generate PNG output, I have a configure check in my program for this, namely echo "set term png" | `which gnuplot` 2>/dev/null && \ gnuplot_png=yes This has worked with versions of gnuplot up to 4.0. I have just updated to version 4.2.0 and it now fails, if the command is not run with the X11 display set. With a non-X11 enabled ssh connection, I get: waverley:~$ echo "set term png" | /usr/local/bin/gnuplot gnuplot: unable to open display '' gnuplot: X11 aborted. With previous gnuplot versions it was not necessary that the DISPLAY variable be set to something valid for X11. Can anyone suggest a workaround for this? Thanks. -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 03:07:09
|
On Thursday 08 March 2007 18:27, Allin Cottrell wrote:
>
> echo "set term png" | `which gnuplot` 2>/dev/null && \
> gnuplot_png=yes
>
> This has worked with versions of gnuplot up to 4.0. I have just
> updated to version 4.2.0 and it now fails, if the command is not
> run with the X11 display set.
I can't reproduce this.
bash-3.1$ unset DISPLAY
bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes
bash-3.1$ echo $png42
yes
> With previous gnuplot versions it was not necessary that the
> DISPLAY variable be set to something valid for X11.
Let's try to pin down exactly what causes the failure.
> Can anyone suggest a workaround for this? Thanks.
Yes. It would be sufficient to pass in GNUTERM=png
(or GNUTERM=<anything but x11> for that matter).
bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2
terminal type is dumb feed 79 24
--
Ethan A Merritt
|
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 03:20:15
|
Ethan A Merritt wrote: > On Thursday 08 March 2007 18:27, Allin Cottrell wrote: > >>echo "set term png" | `which gnuplot` 2>/dev/null && \ >>gnuplot_png=yes >> >>This has worked with versions of gnuplot up to 4.0. I have just >>updated to version 4.2.0 and it now fails, if the command is not >>run with the X11 display set. > > > I can't reproduce this. > > bash-3.1$ unset DISPLAY > bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes > bash-3.1$ echo $png42 > yes > > >>With previous gnuplot versions it was not necessary that the >>DISPLAY variable be set to something valid for X11. > > > Let's try to pin down exactly what causes the failure. I'll make a guess, based upon this comment: > Yes. It would be sufficient to pass in GNUTERM=png > (or GNUTERM=<anything but x11> for that matter). Recall there was a bit of a discussion about the x11 terminal looking for the location of gnuplot_x11 at start up, i.e., part of x11's initialization but since x11 is the default terminal, ostensibly at start up. If the x11 terminal cannot find gnuplot_x11, gnuplot exits. Dan |
|
From: Allin C. <cot...@wf...> - 2007-03-09 03:47:59
|
On Thu, 8 Mar 2007, Daniel J Sebald wrote:
> I'll make a guess, based upon this comment:
>
>> Yes. It would be sufficient to pass in GNUTERM=png
>> (or GNUTERM=<anything but x11> for that matter).
>
> Recall there was a bit of a discussion about the x11 terminal
> looking for the location of gnuplot_x11 at start up, i.e., part
> of x11's initialization but since x11 is the default terminal,
> ostensibly at start up. If the x11 terminal cannot find
> gnuplot_x11, gnuplot exits.
That sounds right. This works fine, I now see:
waverley:~$ echo "set term png" | \
GNUTERM=dumb gnuplot && echo "OK"
OK
But here's the partial "strace" outpuy from my original command:
getuid32() = 501
setuid32(501) = 0
brk(0) = 0x8150000
brk(0x8171000) = 0x8171000
pipe([3, 4]) = 0
pipe([5, 6]) = 0
clone(
gnuplot: unable to open display ''
gnuplot: X11 aborted.
child_stack=0,
flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidp
tr=0xb79b3908) = 560
--- SIGCHLD (Child exited) @ 0 (0) ---
close(4) = 0
close(5) = 0
fcntl64(6, F_GETFL) = 0x1 (flags O_WRONLY)
fstat64(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0
xb7f97000
_llseek(6, 0, 0xbf944474, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(6, "BSR\n", 4) = -1 EPIPE (Broken pipe)
--- SIGPIPE (Broken pipe) @ 0 (0) ---
+++ killed by SIGPIPE +++
Allin Cottrell
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 03:34:51
|
On Thursday 08 March 2007 19:32, Daniel J Sebald wrote:
>
> Recall there was a bit of a discussion about the x11 terminal
> looking for the location of gnuplot_x11 at start up, i.e.,
> part of x11's initialization but since x11 is the default terminal
Yes, but this patch was supposed to fix it:
2006-11-05
* src/term.c (init_term): Normally we initialize the default terminal
immediately on program entry. However, if the default is x11 then defer
initialization until an actual plot command. This mitigates problems
if gnuplot_x11 cannot be started normally, and allows the user to select
a different driver in the case that x11 is the default but is broken.
Bug #1530601
Looks like the patch didn't actually get applied to the 4.2 branch.
Oops.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Allin C. <cot...@wf...> - 2007-03-09 03:35:16
|
On Thu, 8 Mar 2007, Ethan A Merritt wrote:
> On Thursday 08 March 2007 18:27, Allin Cottrell wrote:
>>
>> echo "set term png" | `which gnuplot` 2>/dev/null && \
>> gnuplot_png=yes
>>
>> This has worked with versions of gnuplot up to 4.0. I have just
>> updated to version 4.2.0 and it now fails, if the command is not
>> run with the X11 display set.
>
> I can't reproduce this.
>
> bash-3.1$ unset DISPLAY
> bash-3.1$ echo "set term png" | gnuplot_4.2 2>/dev/null && png42=yes
> bash-3.1$ echo $png42
> yes
Hmm, I'll try running that on the target machine the next time I'm
there. Remotely, via ssh, I'm still getting what I described.
Here's a little more detail (plain "gnuplot" is version 4.2.0):
waverley:~$ echo "set term png" | \
/usr/local/bin/gnuplot-4.0 && echo "OK"
OK
waverley:~$ echo "set term png" | \
/usr/local/bin/gnuplot && echo "OK"
gnuplot: unable to open display ''
gnuplot: X11 aborted.
> Let's try to pin down exactly what causes the failure.
Yes, I'd like to do that, will try some more testing.
>> Can anyone suggest a workaround for this? Thanks.
>
> Yes. It would be sufficient to pass in GNUTERM=png
> (or GNUTERM=<anything but x11> for that matter).
>
> bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2
>
> terminal type is dumb feed 79 24
Yes, that works fine, only you have to parse the response; the
exit status seems to be OK regardless of the GNUTERM setting.
Allin Cottrell
|
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 03:39:44
|
Ethan A Merritt wrote: > On Thursday 08 March 2007 19:32, Daniel J Sebald wrote: > >>Recall there was a bit of a discussion about the x11 terminal >>looking for the location of gnuplot_x11 at start up, i.e., >>part of x11's initialization but since x11 is the default terminal > > > Yes, but this patch was supposed to fix it: > > 2006-11-05 That rings a bell... That was only a few months ago? Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 05:30:13
|
On Thursday 08 March 2007 19:51, Daniel J Sebald wrote:
> Ethan A Merritt wrote:
> > On Thursday 08 March 2007 19:32, Daniel J Sebald wrote:
> >
> >>Recall there was a bit of a discussion about the x11 terminal
> >>looking for the location of gnuplot_x11 at start up, i.e.,
> >>part of x11's initialization but since x11 is the default terminal
> >
> > Yes, but this patch was supposed to fix it:
> >
> > 2006-11-05
>
> That rings a bell... That was only a few months ago?
Right. It wasn't found/reported/whatever until Nov 06 in the
main cvs branch. We had already frozen the code for 4.2
at that point. I don't specifically recall making a decision,
but I guess my feeling was that something that went unnoticed
or at least un-complained-about during 3 years of development
was not a release-critical bug. Especially since there are
obvious work-arounds if needed.
Plus, it's the sort of "fix" that could easily break as many
corner cases as it fixes. Even now that the fix has been in
CVS for 3 months, I wouldn't bet a large amount that it hasn't
broken some corner case that nobody has noticed/reported yet.
The thing is, I still don't quite understand why Allin is
seeing this problem. The original bug report was due
to incomplete installation; gnuplot was built to default to
X11, but the X11 driver (gnuplot_x11) had not actually been
installed. The problem arose because gnulot tried to open a
pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This
is a different case entirely.
Allin: I don't understand why you see this failure mode.
The strace output you posted showed that it *did* find gnuplot_x11,
but gnuplot_x11 couldn't open DISPLAY.
That's annoyng, but it shouldn't be a fatal error for gnuplot
proper. If I test it deliberately, I get this:
bash-3.1$ DISPLAY=junk:0
bash-3.1$ gnuplot_4.2
G N U P L O T
Version 4.2 patchlevel 0
last modified March 2007
System: Linux 2.6.12-24mdksmp
Copyright (C) 1986 - 1993, 1998, 2004, 2007
Thomas Williams, Colin Kelley and many others
Type `help` to access the on-line reference manual.
The gnuplot FAQ is available from
http://www.gnuplot.info/faq/
Send comments and help requests to <gnu...@li...>
Send bug reports and suggestions to <gnu...@li...>
Terminal type set to 'wxt'
gnuplot> set term x11
Terminal type set to 'x11'
Options are '0'
gnuplot> _X11TransSocketINETConnect() can't get address for junk:6000: Name or service not known
gnuplot: unable to open display 'junk:0'
gnuplot: X11 aborted.
gnuplot> set term png
Terminal type set to 'png'
Options are 'nocrop font verdana 12 '
So yes, a bad DISPLAY setting causes gnuplot_x11 to exit.
But the gnuplot session proper is still active and responsive.
So I still can't reproduce Allin's exact problem.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 05:47:56
|
Ethan A Merritt wrote: > The thing is, I still don't quite understand why Allin is > seeing this problem. The original bug report was due > to incomplete installation; gnuplot was built to default to > X11, but the X11 driver (gnuplot_x11) had not actually been > installed. The problem arose because gnulot tried to open a > pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This > is a different case entirely. Oh yeah, I see now. That isn't the same error message as when gnuplot can't find gnuplot_x11. gnuplot_x11 is the one having problems opening the X display. Is there some way for Allin to confirm that the version of gnuplot_x11 for 4.2 was installed properly and it is not the 4.0 version of gnuplot_x11? Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 05:54:18
|
On Thursday 08 March 2007 21:59, Daniel J Sebald wrote: > > Oh yeah, I see now. That isn't the same error message as > when gnuplot can't find gnuplot_x11. gnuplot_x11 is the one having > problems opening the X display. Is there some way for Allin to > confirm that the version of gnuplot_x11 for 4.2 was installed properly > and it is not the 4.0 version of gnuplot_x11? Doesn't matter. No matter how badly gnuplot_x11 dies, it shouldn't do more than generate an error message on the gnuplot end. Apparently that's not the case, but I haven't yet understood the failure path. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 06:09:10
|
Ethan A Merritt wrote:
> On Thursday 08 March 2007 21:59, Daniel J Sebald wrote:
>
>>Oh yeah, I see now. That isn't the same error message as
>>when gnuplot can't find gnuplot_x11. gnuplot_x11 is the one having
>>problems opening the X display. Is there some way for Allin to
>>confirm that the version of gnuplot_x11 for 4.2 was installed properly
>>and it is not the 4.0 version of gnuplot_x11?
>
>
> Doesn't matter. No matter how badly gnuplot_x11 dies, it shouldn't
> do more than generate an error message on the gnuplot end.
> Apparently that's not the case, but I haven't yet understood the
> failure path.
Yeah, that's right. Well, there are a number of conditional compiles in X11_init() that would explain that behavior. There appears to be only one "graceful" exit out of gnuplot from that point:
if (fork() == 0) {
/* child */
[snip]
fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);
perror("Exec failed");
fprintf(stderr,"See 'help x11' for more details\n");
exit(EXIT_FAILURE);
}
But that set group of error messages isn't appearing in Allin's strace.
Might it be that fork() is coming back nozero and gnuplot attempts sending through the pipe and the OS doesn't like that so kills the process?
Dan
|
|
From: Allin C. <cot...@wf...> - 2007-03-09 23:02:05
|
On Fri, 9 Mar 2007, Daniel J Sebald wrote: a patch designed to fix the sort of problem that I reported. I'm now in the same position vis-a-vis the various computers as when I first reported the issue. I'm afraid things get weirder. (1) Before applying Daniel's patch, the situation is as I described yesterday. But, taking Ethan's idea, I also tried echo "show version long" | gnuplot and this worked OK. (2) After applying Daniel's patch and recompiling, my "set term png" echoed to gnuplot produced a failure (as before), but in addition echo "show version long" | gnuplot now produced the same X11 failure! waverley:~$ echo "show version long" | gnuplot gnuplot: unable to open display '' gnuplot: X11 aborted. I then reverted the patch, recompiled, and tried again. At least the results seem stable: "show version long" piped to gnuplot worked, "set term png" failed. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2007-03-09 13:31:19
|
On Thu, 8 Mar 2007, Ethan A Merritt wrote: > The thing is, I still don't quite understand why Allin is > seeing this problem. The original bug report was due > to incomplete installation; gnuplot was built to default to > X11, but the X11 driver (gnuplot_x11) had not actually been > installed. The problem arose because gnulot tried to open a > pipe to gnuplot_x11, but gnuplot_x11 wasn't there. This > is a different case entirely. Yes, this is a bit mysterious. This morning I'm at the machine that I was accessing remotely last night, and if I try the various experiments you mention (e.g. unsetting DISPLAY, or setting it to some invalid value) I get the same results that you report: the x11 terminal won't work (obviously) but gnuplot does not bomb out. My connection last night was a 2-stage ssh session: from a home DSL connection, behind a firewall, to server B on campus, then from server B to machine A, inside the campus firewall. Now I'm on campus, and I've tried ssh'ing from A to B, then back from B to A (with DISPLAY unset) and running my test command: it works OK! Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 05:34:33
|
On Thursday 08 March 2007 19:35, Allin Cottrell wrote: > > bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2 > > > > terminal type is dumb feed 79 24 > > Yes, that works fine, only you have to parse the response; the > exit status seems to be OK regardless of the GNUTERM setting. Were you expecting an error exit status? Why? I would not have expected an error exit from your original test run on gnuplot version 4.0 either. Failing to find a terminal is not a fatal error. It just returns you to the gnuplot command prompt. So when would you ever see an error exit? -- Ethan A Merritt |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 06:11:09
|
Daniel J Sebald wrote: > Yeah, that's right. Well, there are a number of conditional compiles > in X11_init() that would explain that behavior. I meant to say *none* of the conditional compiles would explain the strace sequence Allin reports. Dan |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 06:45:41
Attachments:
endianesstest_djs_8mar2007.patch
|
Daniel J Sebald wrote:
> Ethan A Merritt wrote:
>
>>On Thursday 08 March 2007 21:59, Daniel J Sebald wrote:
>>
>>
>>>Oh yeah, I see now. That isn't the same error message as
>>>when gnuplot can't find gnuplot_x11. gnuplot_x11 is the one having
>>>problems opening the X display. Is there some way for Allin to
>>>confirm that the version of gnuplot_x11 for 4.2 was installed properly
>>>and it is not the 4.0 version of gnuplot_x11?
>>
>>
>>Doesn't matter. No matter how badly gnuplot_x11 dies, it shouldn't
>>do more than generate an error message on the gnuplot end.
>>Apparently that's not the case, but I haven't yet understood the
>>failure path.
>
>
> Yeah, that's right. Well, there are a number of conditional compiles in X11_init() that would explain that behavior. There appears to be only one "graceful" exit out of gnuplot from that point:
>
>
> if (fork() == 0) {
> /* child */
> [snip]
> fprintf(stderr,"Expected X11 driver: %s\n",X11_full_command_path);
> perror("Exec failed");
> fprintf(stderr,"See 'help x11' for more details\n");
> exit(EXIT_FAILURE);
> }
>
> But that set group of error messages isn't appearing in Allin's strace.
>
> Might it be that fork() is coming back nozero and gnuplot attempts sending through the pipe and the OS doesn't like that so kills the process?
Yes, I think it is something along that line. The only difference between 4.0 and 4.2 is the addition of the following at the end of X11_init():
#if defined(WITH_IMAGE) || defined(BINARY_X11_POLYGON)
X11_send_endianess();
#endif
which sends a few characters through the pipe. This code probably shouldn't be run unless there is a valid pipe.
Probably on your system Ethan and mine this is handled more gracefully.
Allin, please try the following patch and rebuild gnuplot to see if this fixes matters.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 07:41:57
|
Daniel J Sebald wrote: > Allin, please try the following patch and rebuild gnuplot to see if this > fixes matters. I put the patch (and variation of it) on SourceForge. I'm fairly certain it's the solution. The routine X11_update_opts() checks for valid X11_ipc. X11_send_endianess() should be doing the same. Thanks Allin, Dan |
|
From: Allin C. <cot...@wf...> - 2007-03-09 13:58:36
|
On Fri, 9 Mar 2007, Daniel J Sebald wrote: > Allin, please try the following patch and rebuild gnuplot to see if this > fixes matters. Thanks, I'll try this tonight. (I can't really test it right now, since I'm not seeing the problem from here.) Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2007-03-09 13:39:26
|
On Thu, 8 Mar 2007, Ethan A Merritt wrote: > On Thursday 08 March 2007 19:35, Allin Cottrell wrote: >>> bash-3.1$ echo "show term" | GNUTERM=dumb gnuplot_4.2 >>> >>> terminal type is dumb feed 79 24 >> >> Yes, that works fine, only you have to parse the response; the >> exit status seems to be OK regardless of the GNUTERM setting. > > Were you expecting an error exit status? Why? > > I would not have expected an error exit from your original > test run on gnuplot version 4.0 either. > Failing to find a terminal is not a fatal error. > It just returns you to the gnuplot command prompt. > So when would you ever see an error exit? I may have misdescribed the outcome, but in the context of a configure check this is what I had in mind: echo "set term png" | gnuplot 2>/dev/null && echo "OK" echo "set term foo" | gnuplot 2>/dev/null && echo "OK" The first command echoes "OK", the second doesn't. Thus I can get a reading on whether the term type is supported without having to parse any gnuplot output. Allin Cottrell |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-03-09 16:23:15
|
On Friday 09 March 2007 05:39, Allin Cottrell wrote:
>
> I may have misdescribed the outcome, but in the context of a
> configure check this is what I had in mind:
>
> echo "set term png" | gnuplot 2>/dev/null && echo "OK"
> echo "set term foo" | gnuplot 2>/dev/null && echo "OK"
>
> The first command echoes "OK", the second doesn't.
Can you point to any place in the documentation that supports
this idea? I have been looking, and can't find anything that
would give the impession that such a test would work.
It is true there is at least one code path that would
result in gnuplot exiting with an error status set, but the
path looks rather fragile to me. It depends on the current
input stream and on whether the "interactive" flag is set,
and anyhow it isn't initialized until the initial terminal
setup is already complete. So I guess I am surprised to
learn that such a test ever worked!
My recommendation for a configuration test is to use the
output of "show version long":
-READLINE +LIBREADLINE +HISTORY -BACKWARDS_COMPATIBILITY +BINARY_DATA
+GD_PNG +GD_JPEG +GD_TTF +GD_GIF +ANIMATION
-NOCWDRC +X11 +X11_POLYGON +MULTIBYTE +USE_MOUSE +HIDDEN3D_QUADTREE
+DATASTRINGS +HISTOGRAMS +OBJECTS +STRINGVARS +MACROS +IMAGE
You can even check these configuration option from inside a gnuplot
script. The current demos do this. For example, image.dem begins with
if ((GPVAL_VERSION == 4.3 || GPVAL_VERSION == 4.2) \
&& (!strstrt(GPVAL_COMPILE_OPTIONS,"+IMAGE"))) \
print ">>> Skipping demo <<<\n" ; \
print "This copy of gnuplot was built without support for plotting images" ; \
exit ;
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Allin C. <cot...@wf...> - 2007-03-09 20:33:20
|
On Fri, 9 Mar 2007, Ethan A Merritt wrote: > On Friday 09 March 2007 05:39, Allin Cottrell wrote: >> >> I may have misdescribed the outcome, but in the context of a >> configure check this is what I had in mind: >> >> echo "set term png" | gnuplot 2>/dev/null && echo "OK" >> echo "set term foo" | gnuplot 2>/dev/null && echo "OK" >> >> The first command echoes "OK", the second doesn't. > > Can you point to any place in the documentation that supports > this idea? I have been looking, and can't find anything that > would give the impession that such a test would work. No, I haven't looked for this in the docs, I just noticed that it worked. Thanks for your further suggestions. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2007-03-09 23:20:25
|
Allin Cottrell wrote: > On Fri, 9 Mar 2007, Daniel J Sebald wrote: > > a patch designed to fix the sort of problem that I reported. > > I'm now in the same position vis-a-vis the various computers as > when I first reported the issue. I'm afraid things get weirder. > > (1) Before applying Daniel's patch, the situation is as I > described yesterday. But, taking Ethan's idea, I also tried > > echo "show version long" | gnuplot > > and this worked OK. > > (2) After applying Daniel's patch and recompiling, my "set term > png" echoed to gnuplot produced a failure (as before), but in > addition > > echo "show version long" | gnuplot > > now produced the same X11 failure! > > waverley:~$ echo "show version long" | gnuplot > > gnuplot: unable to open display '' > gnuplot: X11 aborted. Strange. What is the strace this time? > I then reverted the patch, recompiled, and tried again. At least > the results seem stable: "show version long" piped to gnuplot > worked, "set term png" failed. And the strace for this as well? I just want to confirm that the system is exiting at the same location and it isn't moved somewhere else after the patch. Dan |
|
From: Allin C. <cot...@wf...> - 2007-03-10 00:19:23
|
On Fri, 9 Mar 2007, Daniel J Sebald wrote: > Allin Cottrell wrote: >> >> (2) After applying Daniel's patch and recompiling, my "set term >> png" echoed to gnuplot produced a failure (as before), but in >> addition >> >> echo "show version long" | gnuplot >> >> now produced the same X11 failure! > > Strange. What is the strace this time? I didn't check that; I can, if it's of interest. But here's one more piece of information. I now suspect that this may be a bug in gnome-terminal. I was running the test in gnome-terminal and it occurred to me to try doing the same thing in an xterm: lo and behold, no problem! That is, my original test echo "set term png" | gnuplot && echo "OK" works fine, over the same 2-stage ssh connection from home to campus, when executed in an xterm. All the same, it's bizarre that the problem doesn't occur with older gnuplot versions. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2007-03-10 00:52:41
|
Allin Cottrell wrote:
> On Fri, 9 Mar 2007, Daniel J Sebald wrote:
>
>> Allin Cottrell wrote:
>>
>>>
>>> (2) After applying Daniel's patch and recompiling, my "set term
>>> png" echoed to gnuplot produced a failure (as before), but in
>>> addition
>>>
>>> echo "show version long" | gnuplot
>>>
>>> now produced the same X11 failure!
>>
>>
>> Strange. What is the strace this time?
>
>
> I didn't check that; I can, if it's of interest. But here's one more
> piece of information. I now suspect that this may be a bug in
> gnome-terminal. I was running the test in gnome-terminal and it
> occurred to me to try doing the same thing in an xterm: lo and behold,
> no problem! That is, my original test
>
> echo "set term png" | gnuplot && echo "OK"
>
> works fine, over the same 2-stage ssh connection from home to campus,
> when executed in an xterm.
>
> All the same, it's bizarre that the problem doesn't occur with older
> gnuplot versions.
Yes, it is strange. Apparently xterm is more forgiving, but I think there may still be an issue. I say that because if I comment out all locations where X11_ipc is assigned inside X11_init(), which should be the equivalent of:
RETURN VALUE
The popen function returns NULL if the fork(2) or pipe(2) calls fail,
or if it cannot allocate memory.
gnuplot is exiting with a segfault.
In any case, I think that patch I put on SourceForge should be moved into CVS to make the endianess function consistent with other functions.
Dan
|
