survival bug?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

survival bug?

R devel mailing list
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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug?

Gabriel Becker-2
Hi Terry,

http://win-builder.r-project.org/ and the rhub build service (which can be
invoked by the rhub package) allow on demand checks in windows
environments, though for active debugging the iteration time can be quite
painful.

If you have access, e.g., through your employer, to a windows license you
should also be able to do use VMWare or VirtualBox (I can never remember
which one I like more) to run windows and test that way. This will have
some start up cost in effort but allows active testing and iteration.

Hope that helps,
~G

On Tue, Mar 3, 2020 at 7:00 AM Therneau, Terry M., Ph.D. via R-devel <
[hidden email]> wrote:

> 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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug?

bbolker

  Microsoft offers fully-provisioned but time-limited developer images
for Windows 10 (I think they last for 3 months) for most major VM
platforms (including VirtualBox, which is the one I currently use).
There would certainly be a start-up cost in effort, but probably not any
financial cost.

   cheers
    Ben Bolker

On 2020-03-03 4:02 p.m., Gabriel Becker wrote:

> Hi Terry,
>
> http://win-builder.r-project.org/ and the rhub build service (which can be
> invoked by the rhub package) allow on demand checks in windows
> environments, though for active debugging the iteration time can be quite
> painful.
>
> If you have access, e.g., through your employer, to a windows license you
> should also be able to do use VMWare or VirtualBox (I can never remember
> which one I like more) to run windows and test that way. This will have
> some start up cost in effort but allows active testing and iteration.
>
> Hope that helps,
> ~G
>
> On Tue, Mar 3, 2020 at 7:00 AM Therneau, Terry M., Ph.D. via R-devel <
> [hidden email]> wrote:
>
>> 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]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug?

Simon Urbanek
In reply to this post by Gabriel Becker-2
FWIW Microsoft provides evaluation version of Windows that can be easily installed using VirtualBox and runs for 180 days. One that I believe is the closest to the CRAN setup (Windows 2008) is:

https://www.microsoft.com/en-nz/download/details.aspx?id=11093

You just tell VB to setup a Windows 2008 VM then, select the downloaded ISO as CD-ROM drive and install from it. The installation is fairly easy and then you only have to download Rtools.exe and R from CRAN. I recommend picking a custom location for R that is painless to type, e.g C:\R. To make iteration easier, I also use a shared mount from my machine (e.g. ~/packages -> E:) so I can edit and build the package on my Mac and then just run c:\R\bin\R CMD INSTALL mypackage_0.1-0.tar.gz  in the Windows VM is the same directory (you need to install Guest Additions [see the VB menu] to enable shared directories - alternatively you can also just use SMB shares if you want).

Cheers,
Simon



> On 4/03/2020, at 10:02 AM, Gabriel Becker <[hidden email]> wrote:
>
> Hi Terry,
>
> http://win-builder.r-project.org/ and the rhub build service (which can be
> invoked by the rhub package) allow on demand checks in windows
> environments, though for active debugging the iteration time can be quite
> painful.
>
> If you have access, e.g., through your employer, to a windows license you
> should also be able to do use VMWare or VirtualBox (I can never remember
> which one I like more) to run windows and test that way. This will have
> some start up cost in effort but allows active testing and iteration.
>
> Hope that helps,
> ~G
>
> On Tue, Mar 3, 2020 at 7:00 AM Therneau, Terry M., Ph.D. via R-devel <
> [hidden email]> wrote:
>
>> 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]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug? - solved

R devel mailing list
  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]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>> [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>


        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug? - solved

R devel mailing list
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 <[hidden email]> 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]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel

>>>
>>     [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>


    [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: survival bug? - solved

Tomas Kalibera
In reply to this post by R devel mailing list
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]]
>>>>
>>>> ______________________________________________
>>>> [hidden email] mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ______________________________________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel