Skip to content

[Bioc-devel] Build error - C stack usage is too close to the limit

5 messages · Ko-Kang Kevin Wang, Aaron Lun, Vincent Carey +1 more

Original
Ko-Kang Kevin Wang
# 
Hi all,

I am getting a strange build error message for scMerge (http://bioconductor.org/checkResults/devel/bioc-LATEST/scMerge/malbec1-buildsrc.html) that reads

+ "C stack usage is too close to the limit? on Linux and Mac and
+ "evaluation nested too deeply: infinite recursion? on Windows, when building the vignette file ?scMerge.Rmd?.

However, when I was building the Rmd locally and also on Travis + pkgdown under BioC3.10 (https://travis-ci.org/SydneyBioX/scMerge/builds/566753523), I had no errors. This file has not been edited for 2 months (https://github.com/SydneyBioX/scMerge/blob/master/vignettes/scMerge.Rmd).

Any help would be appreciated.

Thank you
Best Wishes
Kevin

PhD Candidate
Faculty of Science, School of Mathematics and Statistics
THE UNIVERSITY OF SYDNEY
Aaron Lun
# 
One possibility is that this is due to a regression in 
SingleCellExperiment, caused by the altexp updates and other 
refactoring. This should be fixed in 1.7.3, you can check this for 
yourself by installing drisso/SingleCellExperiment off GitHub.

The other moral of the story is to not use serialized high-level 
objects. Serializing basic objects is fine, but the higher up you go, 
the more fragile your code becomes to refactoring. See, for example, the 
scRNAseq data package for how to deliver a SingleCellExperiment to an R 
session without relying on serialized SingleCellExperiments.

-A
On 8/1/19 7:14 PM, Kevin Wang wrote:
Vincent Carey
# 
On Thu, Aug 1, 2019 at 10:36 PM Aaron Lun <
infinite.monkeys.with.keyboards at gmail.com> wrote:

            

      
      
      
    

        
I can confirm this.  Would it then be appropriate for scMerge to add a
(>= 1.7.3) after its Imports: entry for SingleCellExperiment?

            

      
      
      
    

        
I have run into this issue also.  It is convenient to serialize a high-level
object.  Breaking it down to its constituents, and assembling it, is
a lot more effort.  scRNAseq:::.create_sce shows how to reassemble for
SingleCellExperiments.

Is this a principle we want to adopt?  Avoid serializing "non-basic"
objects?
updateObject methods should help centralize the effort to managing object
designs and their implementation.

It seems it would be wise to implement this principle for any resource that
might be used by both release and devel ... even in devel we may see more
breaking changes propagating as S4 classes evolve, if objects are
serialized.
Adding validObject tests in tests/ could reduce surprises.  Helping class
maintainers know what packages have serialized fragile objects might be a
task for BiocPkgTools -- but a nontrivial one.  Maybe a BiocDevTools package
would be more appropriate.  And checking hub elements seems relevant too.

Basically, before we commit changes to a class, it should not be too hard
to assess the downstream effects and notify relevant developers.  The
alternative
of banning serialized S4 objects seems too harsh and possibly ambiguous.
On the other hand it may be necessary to ban serialized S4 in the *Hubs?

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hervé Pagès
    

    

      
      #
    

  


  

      
This is a really important point.

Finding and updating serialized S4 instances that are lying around
as they evolve can be painful and very time-consuming.

We should definitely avoid storing serialized S4 objects on the Hub.
I don't know about ExperimentHub but at least for AnnotationHub I
believe that we've been careful to avoid storing serialized S4
instances there. The S4 objects that land on the user space are
generally assembled on the user side from raw files downloaded from
the Hub.

H.

        
On 8/2/19 02:58, Vincent Carey wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Aaron Lun
    

    

      
      #
    

  


  

          

      
      
      
    

        
I don't think this is really necessary; 1.7.3 will propagate soon
enough, at which point people just need to stay updated.

            

      
      
      
    

        
Well, it *should* have been a transparent change (even for serialized
objects), it's just that there was a bug. This is not surprising - who
knows how many times S4Vectors has broken one of my packages - and my
attitude is to not do anything unless the fail persists in >=3 build
cycles.

-A

        
On Fri, Aug 2, 2019 at 9:19 AM Pages, Herve <hpages at fredhutch.org> wrote: