[Kst] [Bug 118838] New: [patch] getdata: assertion failed on zero read in lincom and multiply
dwiebe at physics.utoronto.ca
Thu Dec 22 04:33:41 CET 2005
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Summary: [patch] getdata: assertion failed on zero read in lincom
Platform: Compiled Sources
AssignedTo: kst kde org
ReportedBy: dwiebe physics utoronto ca
Version: 1.2.0_devel (using KDE KDE 3.4.2)
Installed from: Compiled From Sources
Compiler: gcc (GCC) 3.4.4
The supplied patch fixes a failed assertion in AllocTmpbuff when the read for the first field in a lincom or multiply returns zero frames.
In this case, the unpatched getdata attempts then to allocate a temporary buffer for the second field in the lincom or multiply of length zero, resulting in the failed assertion.
This patch resolves this issue by returning immediately (thus skipping the attempted read of the second field), and reporting to the caller that zero frames have been read. I'm not quite sure that this is the right response in this situation, in light of George's comments on bug 112762 where he says:
>> 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.
That gives me the impression kst assumes it can always read at least one sample, and so getdata returning zero frames read might cause it to be unhappy. However, I can't see how getdata could legitimately return anything else but zero in this case seeing as it hasn't actually read any data.
This bug was encountered with the BLAST map maker (which uses getdata pared out of the kst source tree) when it attempted to read a field which an overworked NFS server had temporarily caused to go away, so the zero read for the field was unexpected and transitory.
This patch depends on the patch provided in bug 118837.
More information about the Kst