Re: [Rd] survival bug? - solved
On 3/5/20 5:39 PM, Therneau, Terry M., Ph.D. via R-devel wrote:
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.
That line read, but did not write, at an invalid memory location. Starting
with the
question of "what C routines have I added or modified most recently" along with
where the
fault appeared to occur in my test suite, I started reading C code and found
one.
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that patients
don't go
backwards in time. Essentially
for (i=0; i< n; i) {
if (id[i] != id[i-1] ) { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure, [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. Que sera sera
In principle out of bounds access to an array, even reading, may not
only return any value that may be there, but cause a memory protection
failure (the memory there is not accessible) or have some other impact.
Reads from memory can also have side effects (other than crashing your
process).
Tomas
A strong thanks to those who gave solid suggestions for bringing up a local
copy of Windows.
Terry T
My latest submission of survival3.1-10 to CRAN fails a check, but only on
windows, which
I don't use.
How do I track this down?
The test in question works fine on my Linux box.
Terry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] survival bug? - solved
I _think_ the relevant section of the C standard is 6.5.6 Additive Operators
Par 8, excerpted here:
> If both the pointer operand and the result point to elements
> of the same array object, or one past the last element of the
> array object, the evaluation shall not produce an overflow;
> otherwise, **the behavior is undefined**.
This is from the [C11 draft][1], though I imagine has been part of the standard
for a while. So by doing id[-1], in this case the pointer operand is id, and
the result is one element _before_ the array object, thus undefined behavior
which is bad news.
I'm not an expert in these matters though.
[1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
On Thursday, March 5, 2020, 11:39:38 AM EST, Therneau, Terry M., Ph.D. via
R-devel wrote:
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.
That line read, but did not write, at an invalid memory location. Starting
with the
question of "what C routines have I added or modified most recently" along with
where the
fault appeared to occur in my test suite, I started reading C code and found
one.
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that patients
don't go
backwards in time. Essentially
for (i=0; i< n; i) {
if (id[i] != id[i-1] ) { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure, [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. Que sera sera
A strong thanks to those who gave solid suggestions for bringing up a local
copy of Windows.
Terry T
>>> My latest submission of survival3.1-10 to CRAN fails a check, but only on
>>> windows, which
>>> I don't use.
>>> How do I track this down?
>>> The test in question works fine on my Linux box.
>>>
>>> Terry
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] survival bug? - solved
I ended up finding the issue by a focused code review.
Once in the past, I had a version that would fail under one architecture but
not another,
in that case some help from Brian Ripley pointed me to the offending line of C
code.
That line read, but did not write, at an invalid memory location. Starting
with the
question of "what C routines have I added or modified most recently" along with
where the
fault appeared to occur in my test suite, I started reading C code and found
one.
Revised code passes tests on the winbuilder site.
For the curious, I had a line asking "is this patient id different than the
last patient
id" in the C routine underneath survcheck(); I'm making sure that patients
don't go
backwards in time. Essentially
for (i=0; i< n; i) {
if (id[i] != id[i-1] ) { ...}
It is still a surprise to me that just LOOKING at this out of range element
would cause a
failure, [i-1] never appears on the left hand side of any expressions in the
... chunk
above. Nevertheless, it was an error. Que sera sera
A strong thanks to those who gave solid suggestions for bringing up a local
copy of Windows.
Terry T
>>> My latest submission of survival3.1-10 to CRAN fails a check, but only on
>>> windows, which
>>> I don't use.
>>> How do I track this down?
>>> The test in question works fine on my Linux box.
>>>
>>> Terry
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
