[BioC] BayesPeak segfault woes
Tim Rayner
tfrayner at gmail.com
Mon Jun 7 17:56:47 CEST 2010
Hi Jonathan,
Thanks very much indeed - the new BayesPeak version does seem to fix
the segfault issue.
Best regards,
Tim
On 4 June 2010 15:26, Jonathan Cairns <Jonathan.Cairns at cancer.org.uk> wrote:
> 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 at 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 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.
>>
>
>
>
>
>
>
>
>
>
>
> 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