[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