Skip to content

[R-pkg-devel] R CMD check getting stalled

10 messages · Chaitanya Joshi, Charles Determan, Dirk Eddelbuettel +4 more

Original
Chaitanya Joshi
# 
Hi There,

Can you please help me with this query please?
Thanks in advance,
Chaitanya

Dr. Chaitanya Joshi

Senior Lecturer,
Department of Statistics,
University of Waikato,
Hamilton, New Zealand.

Webpage: www.cms.waikato.ac.nz/~cjoshi

Office: G3.29
Phone: +64 7 838 4019
On 24/05/2015 8:48 a.m., Chaitanya Joshi wrote:
Charles Determan
# 
Hi Chaitanya,

That is strange the R CMD check is stalling but there didn't appear to be
any attached screenshot.  I would be also beneficial if we could see/access
your source code.  Is your package hosted on GitHub or a similar service?

Regards,
Charles

On Mon, May 25, 2015 at 10:42 PM, Chaitanya Joshi <cjoshi at waikato.ac.nz>
wrote:

  
  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 26 May 2015 at 07:04, Charles Determan wrote:

        
| That is strange the R CMD check is stalling but there didn't appear to be
| any attached screenshot.  I would be also beneficial if we could see/access

We don't do screenshots, and we don't do html email.

| your source code.  Is your package hosted on GitHub or a similar service?

Better approach, and praying that some kind volunteer helps...

Dirk

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
On 26.05.2015 17:33, Dirk Eddelbuettel wrote:

            

      
      
      
    

        
Wild guess: It's not the package but the file system or file permissions 
so that you cannot determine the size.

Best,
Uwe Ligges

  
  


  


      

    

    

      
      

        


  

        

      Chaitanya Joshi
    

    

      
      #
    

  


  

      
Hi all,

Thanks for your suggestions.

1. As I said, the the same package code was running was R.3.1.2 earlier 
and giving no errors... so not sure if it has to do with the package code
2. We checked the permissions issue, with the admin running it and it 
still stalled at the same place
3. Finally, the problem was solved by using the 32-bit platform - it was 
using a 64bit platform and that's apparently why the package was 
stalling (mystery!

We switched the platform to 32-bit and it is now working fine without 
any errors...
Thanks,
Chaitanya

Dr. Chaitanya Joshi

Senior Lecturer,
Department of Statistics,
University of Waikato,
Hamilton, New Zealand.

Webpage: www.cms.waikato.ac.nz/~cjoshi

Office: G3.29
Phone: +64 7 838 4019

        
On 27/05/2015 4:00 a.m., Uwe Ligges wrote:

            

      
      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

          

      
      
      
    

        
Do you have any thoughts on where specifically to look? Permissions of
the library or of the current dir?

I also wondered if it might be caused by a recursive link that caused
the size inspection to never finish, but there aren't any symlinks in
the package.

I have one student in a class of ~60 students who has this problem.
The package source is at https://github.com/hadley/rv2/tree/check-me,
but it seems unlikely to be related to the package as it works for
everyone else.

Hadley

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
I guess a package that was installed by root and later on checked by a 
regular user or some such, so that permissions do not match.

I think I'd try to remove the package from all libraries and try again. 
And note that network drives/mounts may be the source of such a problem 
when some listings are disabled.

Best,
Uwe Ligges

        
On 28.05.2015 23:02, Hadley Wickham wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

      
Ok, it looks like it's actually quite a subtle problem. (Thanks to
Winston Chang for tracking it down). The root of the problem appears
to be the call to du at
https://github.com/wch/r-source/blob/9ffe87264a1cd59a31a829f72d57af0f1bfa327a/src/library/tools/R/check.R#L3639

With 32-bit R Sys.which("du") finds Rtools/bin/du.exe, whereas 64-bit
R finds c:/windows/system32/du.exe (see attached screenshot).

Hadley


On Thu, May 28, 2015 at 4:04 PM, Uwe Ligges

        
<ligges at statistik.tu-dortmund.de> wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Winston Chang
    

    

      
      #
    

  


  

      
I should also mention that on the machine that had this problem, the user
had installed some software that provided the du program in
c:/windows/system32.

On that machine, with 64-bit R:

            

      
      
      
    

        
Copyright (C) 2005-2009 Mark Russinovich

Sysinternals - www.sysinternals.com

            

      
      
      
    

        
-l     Specify subdirectory depth of information (default is all levels).

   -n     Do not recurse.

   -q     Quiet (no banner).

   -u     Count only unique file occurences.

   -v     Show size (in KB) of intermediate directories.

            

      
      
      
    

        
running command '"du"' had status 65535


-Winston

On Thursday, May 28, 2015, Hadley Wickham <h.wickham at gmail.com

        
<javascript:_e(%7B%7D,'cvml','h.wickham at gmail.com');>> wrote:

        

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Henrik Bengtsson
    

    

      
      #
    

  


  

      
[re-sending using from email address for this list]

        
On Thu, May 28, 2015 at 7:53 PM, Hadley Wickham <h.wickham at gmail.com> wrote:

            

      
      
      
    

        
Huh, screenshots? ;)

So, I can reproduce this on Windows 7 64-bit, IFF, I do:

            

      
      
      
    

        
$ echo %PATH%
C:\Rtools\bin;C:\Rtools\gcc-4.6.3\bin;C:\Windows;C:\Windows\system32

$ i386\Rscript.exe --vanilla -e "Sys.which('du')"
                             du
"C:\\Windows\\system32\\du.exe"
$ Rscript.exe --vanilla -e "shell('du')"
27797   ./i386
28413   ./x64
56275   .

$ x64\Rscript.exe --vanilla -e "Sys.which('du')"
                       du
"C:\\Rtools\\bin\\du.exe"
$ Rscript.exe --vanilla -e "shell('du')"
27797   ./i386
28413   ./x64
56275   .

However, without that C:/Windows/system32/du.exe (seems like a
mistake), both R builds finds the one in "C:\\Rtools\\bin\\du.exe".


BTW, this seems to be another example of what was reported in R-devel
thread '[Rd] How best to get around shadowing of executables by
system()'s prepending of directories to Windows' PATH?' on 2015-05-18
(https://stat.ethz.ch/pipermail/r-devel/2015-May/071195.html).


Details on the Rtools that I have:

$ ls -l C:/Rtools/bin/du.exe
-rwxr-xr-x 1 hb mkpasswd 177191 Oct 13  2014 C:/Rtools/bin/du.exe
$ md5sum C:/Rtools/bin/du.exe
408d9043dd90cf90fbde66f8bef2fcbe *C:/Rtools/bin/du.exe
$ cat C:/Rtools/VERSION.txt
Rtools version 3.3.0.1958


/Henrik

        
On Thu, May 28, 2015 at 7:53 PM, Hadley Wickham <h.wickham at gmail.com> wrote: