Skip to content

does segfault mean (always) a bug?

9 messages · Boris Steipe, Duncan Murdoch, lejeczek +2 more

Original
lejeczek
# 
hi eveybody

I'm trying something simple (Biocunductor packages), so 
simple I believe it's example from docs but I get segfault.
I don't suppose incorrect scripting can cause segfault, right?

regards
Boris Steipe
# 
Wrong.


B.
On May 5, 2015, at 2:54 PM, lejeczek <peljasz at yahoo.co.uk> wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On 05/05/2015 2:54 PM, lejeczek wrote:

            

      
      
      
    

        
In R, a segfault always indicates a bug.  What's not so clear is whether
it is a bug in R, a bug in a contributed package, or a bug in some
underlying system library.

If you can only trigger the bug when using a Bioconductor package, then
the first guess is that it is that package, and the maintainer of that
package is in the best position to track it down further.  If you can
simplify the code to trigger it without using any contributed packages,
then it could well be a bug in R, and we'd like to see code to reproduce it.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      lejeczek
    

    

      
      #
    

  


  

      
On 05/05/15 20:36, Duncan Murdoch wrote:

            

      
      
      
    

        
hi Duncan
I remember that this was a principle of most of programming 
languages, only a bug in the code and/or compiler could 
cause segfault.
In my case it is a contributed package, specifically GOSim 
package, I'm not R programmer and I realise my scripting is 
far from good and possibly with errors.
I could send that snippet of the code here if people think 
it can be looked into and segfault could be replicated?
I also emailed the author.

many thanks
P.

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        

        
> On 05/05/2015 2:54 PM, lejeczek wrote:

        
>> hi eveybody
    >> 
    >> I'm trying something simple (Biocunductor packages), so 
    >> simple I believe it's example from docs but I get segfault.
    >> I don't suppose incorrect scripting can cause segfault, right?

    > In R, a segfault always indicates a bug.  What's not so clear is whether
    > it is a bug in R, a bug in a contributed package, or a bug in some
    > underlying system library.

    > If you can only trigger the bug when using a Bioconductor package, then
    > the first guess is that it is that package, and the maintainer of that
    > package is in the best position to track it down further.  If you can
    > simplify the code to trigger it without using any contributed packages,
    > then it could well be a bug in R, and we'd like to see code to reproduce it.
    > Duncan Murdoch

The bug Duncan mentions can also be in the user's R code, outside any package:

If a user does what (s)he should never do, namely directly call
.C(), .Fortran(), .Call() or similar (.Internal(), .External(),..)
it is typically easy to trigger segfaults, and then the bug is
in the user's R code.

Variations of the above involve using the inline package, or
other interfaces to C/C++/... code, libraries, etc: The bug may be in
your code rather than the underlying code which is allowed to
make strong assumptions about how it is called.

Martin Maechler

  
  


  


      

    

    

      
      

        


  

        

      lejeczek
    

    

      
      #
    

  


  

      
On 06/05/15 09:32, Martin Maechler wrote:

            

      
      
      
    

        
not in my case, no of the above call mentioned calls is 
being used, it really is very simple code (possibly with errors)
I know this is not a place to debug anything but if one 
wants to have a look here it is:

library(org.Hs.eg.db)
#library(org.Mm.eg.db)
#library(org.Sc.sgd.db)
library(GOSim)
#library(GO.db)
#setEvidenceLevel(evidences="all", organism="yeast")
#setEvidenceLevel(evidences="all")
setEvidenceLevel(evidences = "all", 
organism=org.Hs.egORGANISM, gomap=org.Hs.egGO)
calc.diffusion.kernel(method="diffKernelLapl", m=5, 
normalization.method="sqrt", DIR="/__.aLocalStorages/1")
#calc.diffusion.kernel(method="diffKernelLLE", m=5, 
normalization.method="sqrt", DIR="/__.aLocalStorages/1")

and:
...
calculating diffusion kernel 'diffKernelLLE' for ontology BP 
using evidence codes 'all' (Homo sapiens) ...
Note: method with signature ?Matrix#matrix? chosen for 
function ?-?,
  target signature ?ddiMatrix#matrix?.
  "ddiMatrix#ANY" would also be valid

  *** caught segfault ***
address 0x7ffedd69e348, cause 'memory not mapped'

Traceback:
  1: E %*% K %*% E
  2: E %*% K %*% E
  3: calc.diffusion.kernel(method = "diffKernelLLE", m = 5, 
normalization.method = "sqrt",     DIR = "/tmp")
aborting ...

regards

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        

        
> On 05/05/15 20:36, Duncan Murdoch wrote:

        
>> On 05/05/2015 2:54 PM, lejeczek wrote:

        
>>> hi eveybody
    >>> 
    >>> I'm trying something simple (Biocunductor packages), so
    >>> simple I believe it's example from docs but I get segfault.
    >>> I don't suppose incorrect scripting can cause segfault, right?
    >> In R, a segfault always indicates a bug.  What's not so clear is whether
    >> it is a bug in R, a bug in a contributed package, or a bug in some
    >> underlying system library.
    >> 
    >> If you can only trigger the bug when using a Bioconductor package, then
    >> the first guess is that it is that package, and the maintainer of that
    >> package is in the best position to track it down further.  If you can
    >> simplify the code to trigger it without using any contributed packages,
    >> then it could well be a bug in R, and we'd like to see code to reproduce it.
    >> 
    >> Duncan Murdoch
    >> 
    > hi Duncan
    > I remember that this was a principle of most of programming 
    > languages, only a bug in the code and/or compiler could 
    > cause segfault.
    > In my case it is a contributed package, specifically GOSim 
    > package, I'm not R programmer and I realise my scripting is 
    > far from good and possibly with errors.
    > I could send that snippet of the code here if people think 
    > it can be looked into and segfault could be replicated?
    > I also emailed the author.

    > many thanks
    > P.

Dear P.,

in the case of segfault from using a contributed package,
you should typically really only email the package maintainer
(which may different than the package authors), and not R-help.
Only if the maintainer does not respond at all (and only if the
package is open source, typically CRAN) should you ask for help here
or another public forum.

(I would also think it to be polite to the maintainer who has
 volunteered her/his code to be used by you if you give him an
 opportunity to see, comment and fix the problem)

Martin Maechler
ETH Zurich

  
  


  


      

    

    

      
      

        


  

        

      William Dunlap
    

    

      
      #
    

  


  

      
It looks like a problem in the Matrix package.  I made the file KE.rda
containing the Matrix objects K and E constructed in calc.diffusion.kernel
by adding a save() call just before where R dies in the original example:

        K = lam$values[1] * I - M
        E = I - matrix(1, ncol = ncol(I), nrow = nrow(I))/ncol(I)
cat("saving K, E, etc. in /tmp/KE.rda\n")
save(K, E, deg, invD, I, W, M, lam, file="/tmp/KE.rda")
cat("    done making the file\n")
        K = E %*% K %*% E

With that file in place I get

            

      
      
      
    

        
R version 3.2.0 (2015-04-16)
Platform: x86_64-unknown-linux-gnu (64-bit)
Running under: Ubuntu precise (12.04.5 LTS)

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] Matrix_1.2-0

loaded via a namespace (and not attached):
[1] grid_3.2.0      lattice_0.20-31

            

      
      
      
    

        
Formal class 'dsyMatrix' [package "Matrix"] with 5 slots
  ..@ x       : num [1:143376676] 1.00 -8.35e-05 -8.35e-05 -8.35e-05
-8.35e-05 ...
  ..@ Dim     : int [1:2] 11974 11974
  ..@ Dimnames:List of 2
  .. ..$ : NULL
  .. ..$ : NULL
  ..@ uplo    : chr "U"
  ..@ factors : list()

            

      
      
      
    

        
Formal class 'dgCMatrix' [package "Matrix"] with 6 slots
  ..@ i       : int [1:487692] 0 69 948 951 1027 1192 1414 1420 1421 1714
...
  ..@ p       : int [1:11975] 0 27 125 147 199 212 221 230 254 274 ...
  ..@ Dim     : int [1:2] 11974 11974
  ..@ Dimnames:List of 2
  .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
"GO:0000018" ...
  .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
"GO:0000018" ...
  ..@ x       : num [1:487692] 32.2163 -0.004674 -0.000722 -0.005316
-0.014022 ...
  ..@ factors : list()

            

      
      
      
    

        
*** caught segfault ***
address 0x7fffa7e1ccf8, cause 'memory not mapped'

Traceback:
 1: EK %*% E
 2: EK %*% E

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection:

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Wed, May 6, 2015 at 1:57 AM, Martin Maechler <

        
maechler at lynne.stat.math.ethz.ch> wrote:

        

            

      
      
      
    

        

      
      
    

        

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

          

      
      
      
    

        
> It looks like a problem in the Matrix package.  
Indeed.

Thanks to Bill Dunlap for the diagnostics below (and other
offline information and) I have been able to fix the bug
yesterday in the R-forge version of Matrix.
The problem was due to using a version of memory allocation
which is known to be quite fast... but is not to be used for
large objects .. which we have here.

I plan to release the amended version of Matrix to CRAN as 

  Matrix_1.2-1  

rather sooner than later.

With thanks to Bill and Pavel,
Martin Maechler
ETH Zurich

    > I made the file KE.rda containing the Matrix objects K and
    > E constructed in calc.diffusion.kernel by adding a save()
    > call just before where R dies in the original example:

    > K = lam$values[1] * I - M
    > E = I - matrix(1, ncol = ncol(I), nrow = nrow(I))/ncol(I)
    > cat("saving K, E, etc. in /tmp/KE.rda\n")
    > save(K, E, deg, invD, I, W, M, lam, file="/tmp/KE.rda")
    > cat("    done making the file\n")
    > K = E %*% K %*% E

    > With that file in place I get
    >> library(Matrix)
    >> load("KE.rda")
    >> sessionInfo()
    > R version 3.2.0 (2015-04-16)
    > Platform: x86_64-unknown-linux-gnu (64-bit)
    > Running under: Ubuntu precise (12.04.5 LTS)

    [ .......... ]

    > other attached packages:
    > [1] Matrix_1.2-0

    > loaded via a namespace (and not attached):
    > [1] grid_3.2.0      lattice_0.20-31
    >> str(E)
    > Formal class 'dsyMatrix' [package "Matrix"] with 5 slots
    > ..@ x       : num [1:143376676] 1.00 -8.35e-05 -8.35e-05 -8.35e-05
    > -8.35e-05 ...
    > ..@ Dim     : int [1:2] 11974 11974
    > ..@ Dimnames:List of 2
    > .. ..$ : NULL
    > .. ..$ : NULL
    > ..@ uplo    : chr "U"
    > ..@ factors : list()
    >> str(K)
    > Formal class 'dgCMatrix' [package "Matrix"] with 6 slots
    > ..@ i       : int [1:487692] 0 69 948 951 1027 1192 1414 1420 1421 1714
    > ...
    > ..@ p       : int [1:11975] 0 27 125 147 199 212 221 230 254 274 ...
    > ..@ Dim     : int [1:2] 11974 11974
    > ..@ Dimnames:List of 2
    > .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
    > "GO:0000018" ...
    > .. ..$ : chr [1:11974] "GO:0000002" "GO:0000003" "GO:0000012"
    > "GO:0000018" ...
    > ..@ x       : num [1:487692] 32.2163 -0.004674 -0.000722 -0.005316
    > -0.014022 ...
    > ..@ factors : list()
    >> EK <- E %*% K
    >> EKE <- EK %*% E

    > *** caught segfault ***
    > address 0x7fffa7e1ccf8, cause 'memory not mapped'

    [...............]

    > On Wed, May 6, 2015 at 1:57 AM, Martin Maechler <

        
> maechler at lynne.stat.math.ethz.ch> wrote:

        
>> >>>>> lejeczek  <peljasz at yahoo.co.uk>
    >> >>>>>     on Wed, 6 May 2015 08:20:46 +0100 writes:
    >>

        
>> > On 05/05/15 20:36, Duncan Murdoch wrote:

        
>> >> On 05/05/2015 2:54 PM, lejeczek wrote:

        
>> >>> hi eveybody
    >> >>>
    >> >>> I'm trying something simple (Biocunductor packages), so
    >> >>> simple I believe it's example from docs but I get segfault.
    >> >>> I don't suppose incorrect scripting can cause segfault, right?
    >> >> In R, a segfault always indicates a bug.  What's not so clear is
    >> whether
    >> >> it is a bug in R, a bug in a contributed package, or a bug in some
    >> >> underlying system library.
    >> >>
    >> >> If you can only trigger the bug when using a Bioconductor package,
    >> then
    >> >> the first guess is that it is that package, and the maintainer of
    >> that
    >> >> package is in the best position to track it down further.  If you
    >> can
    >> >> simplify the code to trigger it without using any contributed
    >> packages,
    >> >> then it could well be a bug in R, and we'd like to see code to
    >> reproduce it.
    >> >>
    >> >> Duncan Murdoch
    >> >>
    >> > hi Duncan
    >> > I remember that this was a principle of most of programming
    >> > languages, only a bug in the code and/or compiler could
    >> > cause segfault.
    >> > In my case it is a contributed package, specifically GOSim
    >> > package, I'm not R programmer and I realise my scripting is
    >> > far from good and possibly with errors.
    >> > I could send that snippet of the code here if people think
    >> > it can be looked into and segfault could be replicated?
    >> > I also emailed the author.
    >> 
    >> > many thanks
    >> > P.
    >> 
    >> Dear P.,
    >> 
    >> in the case of segfault from using a contributed package,
    >> you should typically really only email the package maintainer
    >> (which may different than the package authors), and not R-help.
    >> Only if the maintainer does not respond at all (and only if the
    >> package is open source, typically CRAN) should you ask for help here
    >> or another public forum.
    >> 
    >> (I would also think it to be polite to the maintainer who has
    >> volunteered her/his code to be used by you if you give him an
    >> opportunity to see, comment and fix the problem)
    >> 
    >> Martin Maechler
    >> ETH Zurich