Hi Tim,

I was able to analyse the .bed file you linked to (I assume there is no associated control file?) without any segfaults, using BayesPeak 1.0.1 - see session info below. I committed this version of BayesPeak to the repository yesterday, and since the mac build is now finished (for the record, the 32-bit windows build is not yet finished), you should be able to download it with:

source("http://bioconductor.org/biocLite.R")
biocLite("BayesPeak")

Also, I would suggest you update your version of IRanges to version 1.6.4:

biocLite("IRanges")

and your version of multicore to version 0.1-4 (http://www.rforge.net/multicore/).

Thanks for bringing this issue to my attention - please let me know if this solves the problem or not!

Jonathan



> sessionInfo()
R version 2.11.0 (2010-04-22) 
x86_64-pc-linux-gnu 

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

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

other attached packages:
[1] multicore_0.1-4 BayesPeak_1.0.1 IRanges_1.6.4  

loaded via a namespace (and not attached):
[1] tools_2.11.0




-----Original Message-----
From: Tim Rayner [mailto:tfrayner@gmail.com]
Sent: Thu 03/06/2010 13:45
To: Jonathan Cairns
Cc: Bioconductor
Subject: Re: [BioC] BayesPeak segfault woes
 
Hi Jonathan,

Thanks for the speedy reply. I tried running bayespeak on this file
several times, and each time I got a segfault at roughly the same
spot:

ftp://ftp.ncbi.nih.gov/pub/geo/DATA/supplementary/samples/GSM315nnn/GSM315954/GSM315954_memory%2DCD8%2Dnaive%2DH3K4me3.bed.gz

I'm not sure if it happens in exactly the same place every time, but
when I split the file by chromosome then it is always certain
chromosome files which cause trouble, which suggests it may be
reproducible.

Cheers,

Tim

On 3 June 2010 13:14, Jonathan Cairns <Jonathan.Cairns@cancer.org.uk> wrote:
> Tim,
>
> I fixed a bug which was resulting in segfaults, and plan to commit this
> version to the respository asap. Which of the .bed files in that publication
> were you analysing when the error below occured? (I'd like to check if I can
> reproduce the error on my machine.) Do you know if the error happens in the
> same place every time?
>
> Thanks,
>
> Jonathan
>
> -----Original Message-----
> From: bioconductor-bounces@stat.math.ethz.ch on behalf of Tim Rayner
> Sent: Thu 03/06/2010 12:13
> To: Bioconductor
> Subject: [BioC] BayesPeak segfault woes
>
> Hi,
>
> I'm trying to run the bayespeak function on some BED files published
> by Araki et al. (PMID 19523850, GEO accession GSE12616), and I'm
> having segfault problems which seem to relate to memory usage. I
> originally tried running the function on the whole BED files but that
> ran into problems very quickly, so I've split the BED files up by
> chromosome. Many of these files have now been processed without
> problems, but some give an error message similar to that given below,
> for no immediately obvious reason (i.e., typically it is *not* the
> largest files which yield this error):
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> [0% done] Starting chr13:17927925-114127244:.............
>  *** caught segfault ***
> address 0x110660000, cause 'memory not mapped'
>
> Traceback:
>  1: .Call("bayespeak", as.integer(tr$"+"$norm[659981:720020]),
> as.integer(tr$"-"$norm[659981:720020]),
> as.integer(w$norm[659981:720020]), as.double(w$norm[659981:720020]),
>   as.integer(max(w$norm[659981:720020])), as.integer(60000),
> as.character(ch), start = as.integer(83925925), end =
> as.integer(89929925),     as.integer(bin.size),
> as.integer(iterations), para = as.double(para.list),
> as.double(prior))
>  2: eval(expr, envir, enclos)
>  3: eval(parse(text = x))
>  4: eval(parse(text = x))
>  5: FUN(X[[2L]], ...)
>  6: lapply(S, FUN, ...)
>  7: doTryCatch(return(expr), name, parentenv, handler)
>  8: tryCatchOne(expr, names, parentenv, handlers[[1L]])
>  9: tryCatchList(expr, classes, parentenv, handlers)
> 10: tryCatch(expr, error = function(e) {    call <- conditionCall(e)
>  if (!is.null(call)) {        if (identical(call[[1L]],
> quote(doTryCatch)))             call <- sys.call(-4L)        dcall <-
> deparse(call)[1L]        prefix <- paste("Error in", dcall, ": ")
>   LONG <- 75L        msg <- conditionMessage(e)        sm <-
> strsplit(msg, "\n")[[1L]]        w <- 14L + nchar(dcall, type = "w") +
> nchar(sm[1L], type = "w")        if (is.na(w))             w <- 14L +
> nchar(dcall, type = "b") + nchar(sm[1L],                 type = "b")
>      if (w > LONG)             prefix <- paste(prefix, "\n  ", sep =
> "")    }    else prefix <- "Error : "    msg <- paste(prefix,
> conditionMessage(e), "\n", sep = "")
> .Internal(seterrmessage(msg[1L]))    if (!silent &&
> identical(getOption("show.error.messages"),         TRUE)) {
> cat(msg, file = stderr())        .Internal(printDeferredWarnings())
> }    invisible(structure(msg, class = "try-error"))})
> 11: try(lapply(S, FUN, ...), silent = TRUE)
> 12: sendMaster(try(lapply(S, FUN, ...), silent = TRUE))
> 13: FUN(1:6[[6L]], ...)
> 14: lapply(1:cores, inner.do)
> 15: multicore::mclapply(jobs, function(x) {    eval(parse(text = x))},
> mc.cores = mc.cores)
> 16: bayespeak(bedfiles[n], use.multicore = TRUE, mc.cores = 6)
> 17: doTryCatch(return(expr), name, parentenv, handler)
> 18: tryCatchOne(expr, names, parentenv, handlers[[1L]])
> 19: tryCatchList(expr, classes, parentenv, handlers)
> 20: tryCatch(expr, error = function(e) {    call <- conditionCall(e)
>  if (!is.null(call)) {        if (identical(call[[1L]],
> quote(doTryCatch)))             call <- sys.call(-4L)        dcall <-
> deparse(call)[1L]        prefix <- paste("Error in", dcall, ": ")
>   LONG <- 75L        msg <- conditionMessage(e)        sm <-
> strsplit(msg, "\n")[[1L]]        w <- 14L + nchar(dcall, type = "w") +
> nchar(sm[1L], type = "w")        if (is.na(w))             w <- 14L +
> nchar(dcall, type = "b") + nchar(sm[1L],                 type = "b")
>      if (w > LONG)             prefix <- paste(prefix, "\n  ", sep =
> "")    }    else prefix <- "Error : "    msg <- paste(prefix,
> conditionMessage(e), "\n", sep = "")
> .Internal(seterrmessage(msg[1L]))    if (!silent &&
> identical(getOption("show.error.messages"),         TRUE)) {
> cat(msg, file = stderr())        .Internal(printDeferredWarnings())
> }    invisible(structure(msg, class = "try-error"))})
> 21: try(x <- bayespeak(bedfiles[n], use.multicore = TRUE, mc.cores = 6))
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>
> I've tried switching off the multicore option, but that doesn't seem
> to help. I'm running this using 64-bit R on MacOSX 10.5.8. Has anybody
> else experienced this problem? I'm going to try and break this down to
> a small test case, but given that the problem apparently occurs in the
> C call I'm not tremendously optimistic. I've included my sessionInfo()
> at the end of this email.
>
> Best regards,
>
> Tim Rayner
>
> --
> Bioinformatician
> Smith Lab, CIMR
> University of Cambridge
>
>
>
>> sessionInfo()
> R version 2.11.0 Patched (2010-04-30 r51866)
> x86_64-apple-darwin9.8.0
>
> locale:
> [1] en_GB.UTF-8/en_GB.UTF-8/C/C/en_GB.UTF-8/en_GB.UTF-8
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> other attached packages:
> [1] multicore_0.1-3 BayesPeak_1.0.0 IRanges_1.6.0
>
> _______________________________________________
> Bioconductor mailing list
> Bioconductor@stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/bioconductor
> Search the archives:
> http://news.gmane.org/gmane.science.biology.informatics.conductor
>
>
>
>
>
>
>
> This communication is from Cancer Research UK. Our website is at
> www.cancerresearchuk.org. We are a charity registered under number 1089464
> and a company limited by guarantee registered in England & Wales under
> number 4325234. Our registered address is 61 Lincoln's Inn Fields, London
> WC2A 3PX. Our central telephone number is 020 7242 0200.
>
> This communication and any attachments contain information which is
> confidential and may also be privileged. It is for the exclusive use of the
> intended recipient(s). If you are not the intended recipient(s) please note
> that any form of disclosure, distribution, copying or use of this
> communication or the information in it or in any attachments is strictly
> prohibited and may be unlawful. If you have received this communication in
> error, please notify the sender and delete the email and destroy any copies
> of it.
>
> E-mail communications cannot be guaranteed to be secure or error free, as
> information could be intercepted, corrupted, amended, lost, destroyed,
> arrive late or incomplete, or contain viruses. We do not accept liability
> for any such matters or their consequences. Anyone who communicates with us
> by e-mail is taken to accept the risks in doing so.
>










This communication is from Cancer Research UK. Our website is at www.cancerresearchuk.org. We are a charity registered under number 1089464 and a company limited by guarantee registered in England & Wales under number 4325234. Our registered address is 61 Lincoln's Inn Fields, London WC2A 3PX. Our central telephone number is 020 7242 0200.

This communication and any attachments contain information which is confidential and may also be privileged.   It is for the exclusive use of the intended recipient(s).  If you are not the intended recipient(s) please note that any form of disclosure, distribution, copying or use of this communication or the information in it or in any attachments is strictly prohibited and may be unlawful.  If you have received this communication in error, please notify the sender and delete the email and destroy any copies of it.

E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses.  We do not accept liability for any such matters or their consequences.  Anyone who communicates with us by e-mail is taken to accept the risks in doing so.
	[[alternative HTML version deleted]]

