[Bioc-devel] Error during CHECK on Windows (tokay1)

[Hervé Pagès]

FWIW the build report for BioC release got updated about 2h ago
with today's results and we don't see this CHECK error for
openPrimeR anymore:

 
https://bioconductor.org/checkResults/3.6/bioc-LATEST/openPrimeR/tokay1-checksrc.html

This is typical with race conditions: some days we'll see the error
and some days we won't. Since openPrimeR has not changed between
release and devel, it's possible that we'll sometimes see this error
in devel too.

H.


On 03/22/2018 11:02 AM, Hervé Pagès wrote:
> The build system captures the output of the 'R CMD check' command
> and displays it. If you look at the devel build report you'll
> see that it also displays the content of some of the files produced
> by 'R CMD check':
> 
>    - openPrimeR.Rcheck/00install.out
>    - openPrimeR.Rcheck/tests_i386/testthat.Rout
>    - openPrimeR.Rcheck/tests_x64/testthat.Rout
>    - openPrimeR.Rcheck/examples_i386/openPrimeR-Ex.timings
>    - openPrimeR.Rcheck/examples_x64/openPrimeR-Ex.timings
> 
> Yes it will open these files in order to read their content but
> openPrimeR-Ex_i386.Rout is not one them.
> 
> It also checks that those files exist before trying to open them.
> If they don't exist, they're ignored. This is why the 'Tests output'
> and 'Example timings' sections at the bottom of openPrimeR check
> report in release are empty.
> 
> However I'm pretty confident that 'R CMD check' opens
> openPrimeR-Ex_i386.Rout after running the examples in 32-bit
> mode. I think it parses the file in order to detect/report
> problems that happened during the run of the examples.
> 
> Just to clarify: I don't think the problem is that the file
> doesn't exist when 'R CMD check' tries to open it. I think the
> problem is that some process is still holding on the file (via
> a write connection), which prevents 'R CMD check' from opening
> it (even if it tries to open it in read-only mode).
> 
> Disabling parallel execution in your examples would be very
> informative!
> 
> H.
> 
> 
> On 03/22/2018 10:29 AM, Matthias Döring wrote:
>> Dear Hervé,
>> thanks for the detailed explanation. I have, however, one question. 
>> Isn't this rather a problem with the Bioconductor build system than 
>> with the package itself? I will explain why I think so.
>>  From my limited understanding, it seems to me that the out file from 
>> running the package examples, in this case, "openPrimeR-Ex.Rout" is 
>> not read by R CMD check itself but only written to.
>> So, only after R CMD check has run, should the Bioconductor build 
>> system try to open the file to do some checks (I don't know what it's 
>> checking but apparently there is something of interest in the file).
>>
>>
>> At this point, there should be a check whether the file is available 
>> for reading, shouldn't there be? I took a dive into the past and found 
>> this comment from Martin Morgan to a person that had the same problem 
>> as I, which suggests my view.
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__grokbase.com_t_r_bioc-2Ddevel_11asgm4efj_development-2Dversion-2Dof-2Dbayseq-2Dfailing-2Dcheck-2Don-2Dwindows-2Dmachines&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA&m=4dLit0LWO62L2Nbb1SDhPnTyk0HX5yPPi35QNl604X4&s=27EQuRiPmUYDaFi8VIl4UJ2WS43kJT6sHbKhljxra6M&e= 
>>
>>
>> So I'm not sure if adjusting the parallel execution would be a 
>> permanent fix that would ensure that all Bioconductor packages pass 
>> the checks smoothly on Windows. Maybe Martin could comment on this as 
>> well?
>>
>> Kind regards
>>   Matthias
>>
>>
>> On 03/22/2018 05:08 PM, Hervé Pagès wrote:
>>> Hi Matthias,
>>>
>>> Not sure what's causing this but I just wanted to mention a couple
>>> of things:
>>>
>>> Even though you didn't modify your package, it can start failing
>>> for many reasons. The most common reason is that R or another package
>>> that your package depends on was modified. It turns out that a few
>>> days ago we updated R from 3.4.3 to 3.4.4 on the release build
>>> machines. Not sure that's related to the error you're seeing on
>>> tokay1 but this cannot completely be discarded.
>>>
>>> Unlike Unix-like system, Windows doesn't let a process open a file
>>> if the file is currently in use (by the same or another process).
>>> The "cannot open file 'foo': Permission denied" error is typically
>>> the result of such situation. This type of error can be hard to
>>> reproduce because it won't necessarily happen each time one runs
>>> 'R CMD check' on Windows. It only happens if one process is still
>>> holding on file 'foo' when another process tries to access 'foo'.
>>> But sometimes the process holding on 'foo' finishes a little bit
>>> earlier (and releases the file) or the process trying to access
>>> 'foo' does it a little bit later, and everything is fine.
>>> Because of this, troubleshooting this kind of error (called a
>>> race condition) can be tricky.
>>>
>>> The first thing you could do is disable parallel execution in
>>> your examples and see if that eliminates the issue. If you still
>>> see the error, then you can remove doParallel/foreach from the
>>> equation. If you don't see the error anymore (but you'll have
>>> to wait several build iterations to be sure because you could
>>> just be lucky that the race condition doesn't happen for a few
>>> days in a row), then you can fairly suspect that the problem
>>> has something to do with doParallel/foreach and contact the
>>> doParallel/foreach folks.
>>>
>>> Hope this helps,
>>> H.
>>>
>>>
>>> On 03/22/2018 07:31 AM, Matthias Döring wrote:
>>>> Although I didn't make any changes to my package openPrimeR, it is
>>>> currently not passing the checks on tokay1 due to the following error
>>>> while running the examples:
>>>>
>>>> * checking examples ...
>>>> ** running examples for arch 'i386' ...Warning in file(con, "r") :
>>>>     cannot open file '../openPrimeR-Ex_i386.Rout': Permission denied
>>>> Error in file(con, "r") : cannot open the connection
>>>> Execution halted
>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_release_bioc-2DLATEST_openPrimeR_tokay1-2Dchecksrc.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=HjFin7ZZwuYWdlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4&m=SZhlV-e7h7S6Ndf9G2qUGp37kMZHgjDPmkvI7cCtGDA&s=eK8w8Wfg-rPx9HSrExZjtAqbHQSDmYOxNJvdltvzCTM&e= 
>>>>
>>>>
>>>>
>>>> I've just searched for this type of error and found that it can be
>>>> caused by the parallel backend if it isn't explicitly closed. However,
>>>> I'm not creating clusters manually but rather using the foreach package
>>>> for this purpose, so this shouldn't be the root of the problem.
>>>> Interestingly, there are no problems for the development version on
>>>> tokay2
>>>> (https://urldefense.proofpoint.com/v2/url?u=http-3A__bioconductor.org_checkResults_devel_bioc-2DLATEST_openPrimeR_tokay2-2Dchecksrc.html&d=DwIDaQ&c=eRAMFD45gAfqt84VtBcfhQ&r=HjFin7ZZwuYWdlO8wvE3KmoPwjRiq-bV_UKHWdKLLP4&m=SZhlV-e7h7S6Ndf9G2qUGp37kMZHgjDPmkvI7cCtGDA&s=zAWDhUHJG5jAGFu2WUc1K_uSBXN1daXMN5VVObIUjEk&e=). 
>>>>
>>>>
>>>>
>>>>
>>>> Should I just ignore this problem? Any pointers?
>>>>
>>>>
>>>> Best
>>>>
>>>>    Matthias
>>>>
>>>
>>
> 

-- 
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpages at fredhutch.org
Phone:  (206) 667-5791
Fax:    (206) 667-1319