Version: 1.2.0_svn_460893 (using KDE KDE 3.4.1) OS: Linux With a static dirfile, kst consumes much (but not quite all) CPU cycles when idle. I've confirmed that this doesn't occur with ASCII files. I haven't tried other data sources. I first noticed this with the new LED indicating new data is show, as it seems to flicker/pulsate when kst is consuming all the cpu, although I'm not 100% sure the problem didn't manifest before the LED was added (since it only seems to be a dirfile thing). Perhaps this is even somehow related to the idle crash bug (bug 112689)?
> With a static dirfile, kst consumes much (but not quite all) CPU cycles > when idle. I've confirmed that this doesn't occur with ASCII files. I > haven't tried other data sources. I first noticed this with the new LED It must be datasource related. I don't see the problem with ascii either. Testcase?
On Fri, Sep 16, 2005 at 07:03:30PM -0000, George Staikos wrote: > It must be datasource related. I don't see the problem with ascii either. > Testcase? Ah ha. It's 'MULTIPLY' related (the new feature in getdata). And only when the two fields being multiplied have different numbers of samples per frame. I should have realized it was something like that. Testcase: Use the dirfile_maker, and add the following line to the format file: mult MULTIPLY sine ssine Then open kst and plot the field mult.
Confirmed
The problem is related to the fact that INDEX has a number of samples far lower than mult (or some of the other fields).
(Or to be more specific, samplesPerFrame of mult is > samplesPerFrame of INDEX)
The bug is due to SVN revision 458719: ------------------------------------------------------------------------ r458719 | truch | 2005-09-08 18:51:31 -0400 (Thu, 08 Sep 2005) | 7 lines Apply Don Wiebe's getdata modifications: Adds a MULTIPLY derived field for multiplying two fields. Adds the ability to LINCOM fields with different numbers of samples per frame. Also applies to new MULTIPLY fields. There were some changes like this: + if (n_read2 * spf1 < *n_read * spf2) { + *n_read = n_read2 * spf1 / spf2; + } KstRVector expects that it can read one sample from a frame, however. This means that n_read is 1 and n_read2 is 0, so n_read is adjusted to 0. This is wrong. n_read should be 1 still, and Kst keeps trying to read this sample over and over. The obvious fix is to skip this if n_read2 is 0. Any comments?
SVN commit 469422 by staikos: Return properly when the second read returns 0. Please comment in the bug report if this doesn't do what you expect. BUG: 112762 M +2 -2 getdata.c --- trunk/extragear/graphics/kst/kst/datasources/dirfile/getdata.c #469421:469422 @@ -1199,7 +1199,7 @@ return_type, tmpbuf, error_code); - if (n_read2 * spf1 != *n_read * spf2) { + if (n_read2 > 0 && n_read2 * spf1 != *n_read * spf2) { *n_read = n_read2 * spf1 / spf2; } @@ -1265,7 +1265,7 @@ 0, *n_read * spf2 / spf1, return_type, tmpbuf, error_code); - if (n_read2 * spf1 < *n_read * spf2) { + if (n_read2 > 0 && n_read2 * spf1 < *n_read * spf2) { *n_read = n_read2 * spf1 / spf2; } recurse_level--;