Menu
▾
▴
gnuplot-beta
|
From: Bastian M. <bma...@we...> - 2006-06-28 14:34:11
|
Hi, I am experiencing spurious crashes here when using history command recall, e.g. the sequence hi !cd hi !load hi !load makes wgnuplot segfault (sometimes) independent of the script loaded. Has anybody else seen behaviour like that? I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6) on Windows XP and gnuplot's built-in readline library. Where exactly gnuplot crashes depends on the usage history of the gnuplot session. Sometimes it's in history_command(), but I have seen load_file() and set_label() as well. Bastian --=20 Bastian M=E4rkisch Physikalisches Institut, Universit=E4t Heidelberg |
|
From: Petr M. <mi...@ph...> - 2006-06-28 14:54:52
|
> I am experiencing spurious crashes here when using > history command recall, e.g. the sequence > > hi !cd > hi !load > hi !load > > makes wgnuplot segfault (sometimes) independent of the script loaded. > Has anybody else seen behaviour like that? > I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6) > on Windows XP and gnuplot's built-in readline library. I don't see this on Linux with neither gnuplot's or GNU readline. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-06-28 16:42:01
|
Petr Mikulik wrote:
>>I am experiencing spurious crashes here when using
>>history command recall, e.g. the sequence
>>
>>hi !cd
>>hi !load
>>hi !load
>>
>>makes wgnuplot segfault (sometimes) independent of the script loaded.
>>Has anybody else seen behaviour like that?
>>I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6)
>>on Windows XP and gnuplot's built-in readline library.
>
>
> I don't see this on Linux with neither gnuplot's or GNU readline.
Umm, I got one right away:
gnuplot> hi
1 (null)
Segmentation fault
I'll investigate.
Dan
|
|
From: Bastian M. <bma...@we...> - 2006-06-28 16:48:57
|
Daniel J Sebald wrote: > Petr Mikulik wrote: >>> I am experiencing spurious crashes here when using >>> history command recall, e.g. the sequence >>> >>> hi !cd >>> hi !load >>> hi !load >>> >>> makes wgnuplot segfault (sometimes) independent of the script loaded.= >>> Has anybody else seen behaviour like that? >>> I'm using the latest CVS snapshot compiled with makefile.nt (MSVC 6) >>> on Windows XP and gnuplot's built-in readline library. >> >> I don't see this on Linux with neither gnuplot's or GNU readline. >=20 > Umm, I got one right away: >=20 > gnuplot> hi > 1 (null) > Segmentation fault >=20 > I'll investigate. >=20 Thanks, I appreciate that. As I was the last to mess with the histroy stu= ff, the error was probably introduced by me. Btw. I compiled wgnuplot with GNUPLOT_HISTORY defined and my history wasn= 't empty (obviously). Bastian > Dan >=20 --=20 Bastian M=E4rkisch Physikalisches Institut, Universit=E4t Heidelberg Philosophenweg 12 69120 Heidelberg Tel.: +49-6221-549239 Fax: +49-6221-549343 |
|
From: Daniel J S. <dan...@ie...> - 2006-06-28 21:36:51
Attachments:
history-djs-28jun2006.patch
|
Bastian Maerkisch wrote:
>>Umm, I got one right away:
>>
>>gnuplot> hi
>> 1 (null)
>>Segmentation fault
>>
>>I'll investigate.
>>
>
>
> Thanks, I appreciate that. As I was the last to mess with the histroy stuff,
> the error was probably introduced by me.
The problem actually appears to be something that was sitting in the code for quite a while. Did someone reactivate something recently to choose a different history? (I think someone did, because I now have a history buffer I never had and I'm very happy for it.)
SourceForge bugs-report isn't working right now. I've attached the patch here and will add it to S.F. later.
The problem, as I figure is when the user asked for a history length that was greater than the number entries in the history buffer. In that case, "start" was never being set.
OK, now some comments. I see this goes back a few weeks on the list and understand why the behavior is what it currently is. But I have a concern with behavior and we might be able to resolve something here.
1) By shuffling around the command line entries when placing them in the history buffer, the history becomes inaccurate in a significant sense. A user, especially a new one, will fret "Now what did I type to get that to work?". He or she will look back at the history and see something that in no way reflects what was typed if there are repeat commands.
The other thing I don't like is that when placing a command line entry into the list, in order to do this little shuffling thing, one has to search back through the history time and time again. If the history buffer gets very long with one unique command after another, that's a lot of horsepower going to maintaining the buffer on a consistent basis. Sure, it might be small compared to what gnuplot usually does, but my preference always leans toward efficiency.
Here is what I'd like to see to try and combine desires:
o The history buffer keeps a linear history of commands that have been entered. That way, putting a new entry in the list is straightforward.
o With that, hitting the up arrow will have a nice memory. I often use the up arrow in quick succession if I know how far back I want to recall commands. How can I rely on that if the entries are being shuffled about?
o Even if the history buffer is linear, we can always make the display of that buffer behave just like it currently does with a few little programming tricks. But losing the original sequence of things means we can never get things back. Would it make sense to have an option for history:
gnuplot> history # {linear | condensed}
o Was the reason for the current behavior to make sure the history buffer doesn't get so big? We should also have a "depth" option. Otherwise the history buffer continues to grow, especially when it recalls the previous history from a file on startup. A double linked-list might be good for that so we can dump things off the beginning of the list.
o We should keep track of the history length so that when "history #" is used for loops can break out right away rather than having to recompute the history length.
o A way to flush the history would be nice. "history flush"?
o Some way of recalling a particular line into the command line buffer would be nice. history 20 will display a nice view of recent history. But if the command I want is 15 back I would have to hit the up arrow 15 times. What sould be nice is if I could type "history 233 get" and it puts that command on the screen ready for me to hit return or use the arrow keys to edit it.
2) Minor thing: When I type "history", should the word "history" appear as the most recent entry? It doesn't matter too much really, but somehow I feel it shouldn't be displayed.
Dan
|
|
From: Petr M. <mi...@ph...> - 2006-06-28 22:08:22
|
> The problem actually appears to be something that was sitting in the code for
> quite a while.
> SourceForge bugs-report isn't working right now. I've attached the patch
I've committed it to cvs.
> OK, now some comments.
>
> 1) By shuffling around the command line entries when placing them in the
> history buffer, the history becomes inaccurate in a significant sense. A
> user, especially a new one, will fret "Now what did I type to get that to
> work?". He or she will look back at the history and see something that in no
> way reflects what was typed if there are repeat commands.
It reflects all commands he has entered. By means of them, the last plot can
be easily reproduced.
The current behaviour saves his nerves using "up arrow" key to go always
through last 10 replot commands, for example.
> the list, in order to do this little shuffling thing, one has to search back
> through the history time and time again. If the history buffer gets very
> long with one unique command after another, that's a lot of horsepower going
> to maintaining the buffer on a consistent basis.
There is a limit of 1000 commands stored in the history if I remember
correctly, so there will be max 1000 times strcmp(). It will take much less
time then drawing any graph or writing a character.
> tricks. But losing the original sequence of things means we can never get
> things back.
Write your commands into a script file.
Keep interactive editing easy.
> Would it make sense to have an option for history:
>
> gnuplot> history # {linear | condensed}
Maybe, if some people like the "linear".
> o Was the reason for the current behavior to make sure the history buffer
> doesn't get so big?
No, see above.
> We should also have a "depth" option.
yes, and
set historyfile depth 0
would avoid saving (reading also?) of the history file
> o A way to flush the history would be nice. "history flush"?
maybe
> 2) Minor thing: When I type "history", should the word "history" appear as
> the most recent entry? It doesn't matter too much really, but somehow I feel
> it shouldn't be displayed.
sometimes you like to have in history, sometimes not; so I want to let it
in the history
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-28 22:52:57
|
Petr Mikulik wrote:
>> The problem actually appears to be something that was sitting in the
>> code for quite a while.
>> SourceForge bugs-report isn't working right now. I've attached the patch
>
>
> I've committed it to cvs.
>
>
>> OK, now some comments.
>>
>> 1) By shuffling around the command line entries when placing them in
>> the history buffer, the history becomes inaccurate in a significant
>> sense. A user, especially a new one, will fret "Now what did I type
>> to get that to work?". He or she will look back at the history and
>> see something that in no way reflects what was typed if there are
>> repeat commands.
>
>
> It reflects all commands he has entered. By means of them, the last plot
> can be easily reproduced.
>
> The current behaviour saves his nerves using "up arrow" key to go always
> through last 10 replot commands, for example.
Yeah, I can see how that would be nice. Tossing out repeated commands helps, but it doesn't totally rid the issue of the command you want being far back in the history buffer. That is sort of the reason for displaying the history. There should be a way to quickly get the one command you see on the displayed list. (Of course, in linux I can simply use the middle button of the mouse to grab that command.) "hi 34 get" would be nice.
> Write your commands into a script file.
> Keep interactive editing easy.
That is what I do. I've always found it easy to do that sort of thing.
>> Would it make sense to have an option for history:
>>
>> gnuplot> history # {linear | condensed}
>
>
> Maybe, if some people like the "linear".
How about this? up-arrow key goes backward through *unique* history entries (current behavior), <SHIFT>-up-arrow key goes backward through all history. That might be nice. Is there a precedence for such a thing in readline types of scenarios?
Anyway, post 4.2 discussion...
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-28 23:39:00
|
On Wednesday 28 June 2006 03:07 pm, Petr Mikulik wrote:
> > The problem actually appears to be something that was sitting in the code for
> > quite a while.
> > SourceForge bugs-report isn't working right now. I've attached the patch
>
> I've committed it to cvs.
Unfortunately, I think this was a step backwards.
Before this went in, I was unable to replicate the reported crashes.
I'm sure they were real, but they must have been hard to trigger.
With this new patch in cvs, I now get the following:
gnuplot> history !re
Executing:
reset
gnuplot> history !rep
Executing:
replot
^
no previous plot
gnuplot>
*** glibc detected *** malloc(): memory corruption: 0x081e8260 ***
So I think there is a serious memory error in this code that
was just added.
Please, can we not add bunches of new and untested code to CVS
at this point? It's a bad idea when we're trying to tie up all
the loose ends for a release. The risk of introducing serious
new bugs is greater than the benefit from fixing minor annoyances.
Ethan
>
>
> > OK, now some comments.
> >
> > 1) By shuffling around the command line entries when placing them in the
> > history buffer, the history becomes inaccurate in a significant sense. A
> > user, especially a new one, will fret "Now what did I type to get that to
> > work?". He or she will look back at the history and see something that in no
> > way reflects what was typed if there are repeat commands.
>
> It reflects all commands he has entered. By means of them, the last plot can
> be easily reproduced.
>
> The current behaviour saves his nerves using "up arrow" key to go always
> through last 10 replot commands, for example.
>
>
> > the list, in order to do this little shuffling thing, one has to search back
> > through the history time and time again. If the history buffer gets very
> > long with one unique command after another, that's a lot of horsepower going
> > to maintaining the buffer on a consistent basis.
>
> There is a limit of 1000 commands stored in the history if I remember
> correctly, so there will be max 1000 times strcmp(). It will take much less
> time then drawing any graph or writing a character.
>
> > tricks. But losing the original sequence of things means we can never get
> > things back.
>
> Write your commands into a script file.
> Keep interactive editing easy.
>
>
> > Would it make sense to have an option for history:
> >
> > gnuplot> history # {linear | condensed}
>
> Maybe, if some people like the "linear".
>
> > o Was the reason for the current behavior to make sure the history buffer
> > doesn't get so big?
>
> No, see above.
>
> > We should also have a "depth" option.
>
> yes, and
> set historyfile depth 0
> would avoid saving (reading also?) of the history file
>
> > o A way to flush the history would be nice. "history flush"?
>
> maybe
>
> > 2) Minor thing: When I type "history", should the word "history" appear as
> > the most recent entry? It doesn't matter too much really, but somehow I feel
> > it shouldn't be displayed.
>
> sometimes you like to have in history, sometimes not; so I want to let it
> in the history
>
> ---
> PM
>
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 00:03:05
|
Ethan A Merritt wrote: > On Wednesday 28 June 2006 03:07 pm, Petr Mikulik wrote: > >>>The problem actually appears to be something that was sitting in the code for >>>quite a while. >>>SourceForge bugs-report isn't working right now. I've attached the patch >> >>I've committed it to cvs. > > > Unfortunately, I think this was a step backwards. > Before this went in, I was unable to replicate the reported crashes. > I'm sure they were real, but they must have been hard to trigger. > With this new patch in cvs, I now get the following: > > gnuplot> history !re > Executing: > reset > gnuplot> history !rep > Executing: > replot > ^ > no previous plot > gnuplot> > *** glibc detected *** malloc(): memory corruption: 0x081e8260 *** > > So I think there is a serious memory error in this code that > was just added. That or you found another bug. I didn't touch anything with the malloc() command or the ! form of history. Only the portion that displays the code, write_history_n(). The command sequence above should not make a call to write_history_n(). Give me a couple hours to see if there is another bug here. I have tried your command sequence and can reproduce something similar. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 00:37:08
|
Daniel J Sebald wrote:
> That or you found another bug. I didn't touch anything with the malloc() command or the ! form of history. Only the portion that displays the code, write_history_n(). The command sequence above should not make a call to write_history_n().
>
> Give me a couple hours to see if there is another bug here. I have tried your command sequence and can reproduce something similar.
I have a feeling that this bug resides in command.c. There is quite a problem here. I get a little more information than what Ethan did:
Terminal type set to 'x11'
gnuplot> history !re
Executing:
replot
^
no previous plot
gnuplot> history !re
^
recurrency forbidden
gnuplot> history !re
Segmentation fault
That "recurrecy forbidden" is the tip off. Here is the questionable hunk of code in command.c (not help.c):
/* execute the command "name" */
char *copy_name = gp_strdup(name);
save_input_line = gp_input_line;
save_c_token = c_token;
save_input_line_len = gp_input_line_len;
flag = 1;
gp_input_line = copy_name;
printf(" Executing:\n\t%s\n",name);
bad> do_line();
free(copy_name);
gp_input_line = save_input_line;
c_token = save_c_token;
gp_input_line_len = save_input_line_len;
num_tokens = scanner(&gp_input_line, &gp_input_line_len);
flag = 0;
It is of the variety that I've never liked, where some variables are temporarily saved, change, do something, then change them back.
OK, so the program searches through the history and finds a command that matches. It comes to the above code, grabs some memory, rearranges some variables, then reaches that line of code I marked as "bad". But look at the "replot" command above, it calls an internal_error() in all likelihood, in which case the program never returns from "do_line()", copy_name is never freed, *gp_input_line* is pointing to a bogus, less than 1024 character string (could be a problem), and flag never gets set to zero (hence the "recurrency forbidden" message I'm getting.
There is a considerable bug. How do we go about fixing that?
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 02:20:50
|
Daniel J Sebald wrote: > There is a considerable bug. How do we go about fixing that? I may have a solution, if anyone else has started looking at this. This may not be as difficult as it was made to be. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-29 17:46:58
|
On Thursday 29 June 2006 10:10 am, you wrote: > > I do see some more dodgy potential memory leak code in command.c. That use of do_line() followed by a free of a non-static memory pointer: (from do_string, ... in most cases the command given to it by the mouse and so on should not fail) > > do_line(); > strcpy(gp_input_line, orig_input_line); > free(orig_input_line); You mean because it might int_error() inside do_line()? The possibility of a memory leak triggered only by a user error doesn't bother me nearly as much as a memory that can happen during correct usage. Presumably if it's a script that errors out, they've got bigger problems than the memory leak. I did find one other thing inadvertantly while testing on VMS, however. Some of the demos use deprecated syntax that only works if you build with BACKWARDS_COMPATIBLE defined. They should be fixed to use the current syntax, since they serve as coding examples. I logged a feature request to track this. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 18:03:13
|
Ethan A Merritt wrote: > On Thursday 29 June 2006 10:10 am, you wrote: > >>I do see some more dodgy potential memory leak code in command.c. That use of do_line() followed by a free of a non-static memory pointer: (from do_string, ... in most cases the command given to it by the mouse and so on should not fail) >> >> do_line(); >> strcpy(gp_input_line, orig_input_line); >> free(orig_input_line); > > > You mean because it might int_error() inside do_line()? Yes. > The possibility of a memory leak triggered only by a user error doesn't > bother me nearly as much as a memory that can happen during correct > usage. Presumably if it's a script that errors out, they've got bigger > problems than the memory leak. I'm a-r that way, I guess; don't like losing memory--probably because I work on other platforms where there isn't the abundance of memory like on a general computer system. > I did find one other thing inadvertantly while testing on VMS, however. > Some of the demos use deprecated syntax that only works if you build > with BACKWARDS_COMPATIBLE defined. They should be fixed to use the > current syntax, since they serve as coding examples. > I logged a feature request to track this. OK. Dan |
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 19:28:11
|
Ethan A Merritt wrote:
> I did find one other thing inadvertantly while testing on VMS, however.
> Some of the demos use deprecated syntax that only works if you build
> with BACKWARDS_COMPATIBLE defined. They should be fixed to use the
> current syntax, since they serve as coding examples.
> I logged a feature request to track this.
The word "below" for the key was deprecated? ("under" still works.) I assume you want us to remove any examples of deprecated syntax from gnuplot.doc as well.
Dan
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-06-29 20:06:09
|
On Thursday 29 June 2006 12:37 pm, Daniel J Sebald wrote:
>
> The word "below" for the key was deprecated?
> ("under" still works.) I assume you want us to remove any
> examples of deprecated syntax from gnuplot.doc as well.
Apparently so. Maybe it was unintentional. I don't care
whether you reinstate "below" or change the docs and the
demos. Just so long as they agree with each other.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Daniel J S. <dan...@ie...> - 2006-06-29 20:56:46
|
Ethan A Merritt wrote:
> On Thursday 29 June 2006 12:37 pm, Daniel J Sebald wrote:
>
>>The word "below" for the key was deprecated?
>>("under" still works.) I assume you want us to remove any
>>examples of deprecated syntax from gnuplot.doc as well.
>
>
> Apparently so. Maybe it was unintentional. I don't care
> whether you reinstate "below" or change the docs and the
> demos. Just so long as they agree with each other.
I seem to recall a discussion where no decision was made to deprecate the key settings. Therefore, I will leave any reference to "below" and "under" in the documentation gnuplot.doc, but I have removed all use of these in the demos.
For "set title" and "set label" I've made sure no outdated syntax appears in gnuplot.doc and removed all use from the demos.
A patch is on SourceForge.
One bug resulted from the switchover to non-compatible compile--rainbow.dem.
Dan
PS: rectangle.dem "Oooo! Ahhh!" (getting read for the fireworks)
|
