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