[BioC] BayesPeak segfault woes

Tim Rayner tfrayner at gmail.com
Thu Jun 3 14:45:25 CEST 2010


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 at 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 at 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 at 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.
>



More information about the Bioconductor mailing list