Re: [Gnuplot-info] gnuplot stuck at 100% CPU when put in background in a shell script

[Cook, R. <co...@ll...>]

Sorry, I was not clear.  This is not a desktop machine.  This is a large cluster with many users and part of my role is to make gnuplot work well on it.  Taking 100% cpu on the login node of our cluster with hundreds of users is a bad thing actually and we try to avoid it.  

I tried gnuplot 4.6.0 and it has the same behavior. 

Compiling without readline might or might not solve the problem, but creates a worse one in my view -- readline is a "necessary convenience."  :-)  I can also launch gnuplot without wrapping it in a shell script, but this again is not a desirable solution.  Or we could use Tecplot instead, but gnuplot has some really sweet features and is very popular here.    

My question is, what is it about being put into the background that causes gnuplot to spin up to 100% CPU looking for a keystroke?  

Thanks
-- Rich 

On Sep 7, 2012, at 11:41 PM, walter harms <wh...@bf...> wrote:

> hi,
> taking 100% cpu time is not a bad thing. that simply means it takes all powers
> it can get to do its job. the problems start when you can not start a second programm
> anymore because the system is so busy.
> 
> The first question is always:
> does the latest version 4.6 behave the same ? (maybe the bug is fixed already)
> 
> to establish that libreadline is the problem, can you create a version of gnuplot without
> libreadline ?
> 
> 
> re,
> wh
> 
> 
> 
> Am 08.09.2012 02:40, schrieb Cook, Rich:
>> Hello, 
>> I'm sorry for such an odd question as a newbie poster. 
>> I have built and installed gnuplot and wrapped it in a wrapper script.  The script simply makes a usage entry in a database, calls gnuplot, then notes that it exits.  I'm including the script below.  
>> 
>> Anyhow, when the user runs this script and puts it into the background, gnuplot immediately starts taking up 100% of a CPU, spinning in readline.  This only happens when gnuplot is wrapped in this way, not when it's called directly.  I would like to avoid this behavior, obviously, but I would also like to continue using a wrapper script.  What is it about being called from a script that is causing this odd behavior on gnuplot's part?  
>> 
>> Thanks.  
>> 
>> Here's a stack trace from a debugger of gnuplot when it's hammering our CPU:  
>> Stack Trace
>>     tcsetattr,           FP=7fffffffd060
>>     rl_tty_unset_default_bindings, FP=7fffffffd080
>>     rl_deprep_terminal,  FP=7fffffffd090
>>     rl_cleanup_after_signal, FP=7fffffffd0a0
>>     rl_reset_after_signal, FP=7fffffffd140
>>     rl_read_key,         FP=7fffffffd160
>>     readline_internal_char, FP=7fffffffd180
>>     readline,            FP=7fffffffd190
>> C    read_line,           FP=7fffffffd1e0
>> C    com_line,            FP=7fffffffd1f0
>> C    main,                FP=7fffffffd3e0
>>     __libc_start_main,   FP=7fffffffd4a0
>>     _start,              FP=7fffffffd4b0
>> 
>> 
>> Here's the wrapper script:  
>> 
>> #!/usr/bin/env bash
>> 
>> IMG_TRACK=${IMG_TRACK:-/usr/local/tools/imgtrack-1.0/bin/imgtrack}
>> if [ -f $IMG_TRACK ]; then 
>>    $IMG_TRACK BEGIN gnuplot-4.4.3 $0 "$@"
>> fi
>> /usr/local/tools/gnuplot-4.4.3/bin/gnuplot.real "$@"
>> _value=$?
>> if [ -f $IMG_TRACK ]; then 
>>    $IMG_TRACK END gnuplot-4.4.3 $0 "$@"
>> fi
>> exit $_value
>> 
>> 
>> 

Rich Cook

--------------------------------------
There is no real you, only neurons firing.  If you understand this, then you know you always have a choice.  Buddha says, "Wake up."  
--------------------------------------