From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 166C67F0F9 for ; Wed, 25 Nov 2015 19:23:47 +0100 (CET) IronPort-PHdr: 9a23:mByOMRDKmChE2GjuhO4LUyQJP3N1i/DPJgcQr6AfoPdwSP7/pMbcNUDSrc9gkEXOFd2CrakU1qyJ4+u5AT1IyK3CmU5BWaQEbwUCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYsExnyfTB4Ov7yUtaLyZ/niqbtq9aKO1QArQH+SI0xBS3+lR/WuMgSjNkqAYcK4TyNnEF1ff9Lz3hjP1OZkkW0zM6x+Jl+73YY4Kp5pIYTGZn9Kq8xSLgdCDU9L0g04tfqvF/NV1ih/HwZB1mIiIRLNCXJ8xD8FsP8vjT7sKl43GydNsTzSZg5RTO46KQtThL03nRUfwUl+X3a35QjxJlQpwis8kRy Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=edwin+ml-ocaml@etorok.net; spf=Pass smtp.mailfrom=edwin+ml-ocaml@etorok.net; spf=None smtp.helo=postmaster@mail.etorok.net Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 62.210.252.135 as permitted sender) identity=mailfrom; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail.etorok.net) identity=helo; client-ip=62.210.252.135; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D5AQBa/FVW/4f80j5egztTb65Rj2MBDYFmHYVyAoFDOBQBAQEBAQEBAYEJgi2CCAEBBAwmAQ0VGAsCAQ4LGAkTAw8JAwIBAgEzEhMGAgKIFQMWCa0GhVqLPAELARkBBotSglOBbwKEdYYWDJA6hSiGHYFwlQiHVh8BAUKEBjw0g2OBSQEBAQ X-IPAS-Result: A0D5AQBa/FVW/4f80j5egztTb65Rj2MBDYFmHYVyAoFDOBQBAQEBAQEBAYEJgi2CCAEBBAwmAQ0VGAsCAQ4LGAkTAw8JAwIBAgEzEhMGAgKIFQMWCa0GhVqLPAELARkBBotSglOBbwKEdYYWDJA6hSiGHYFwlQiHVh8BAUKEBjw0g2OBSQEBAQ X-IronPort-AV: E=Sophos;i="5.20,343,1444687200"; d="scan'208";a="189110036" Received: from mail.etorok.net ([62.210.252.135]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Nov 2015 19:23:31 +0100 Received: by mail.etorok.net (OpenSMTPD) with ESMTP id 5c206dbb for ; Wed, 25 Nov 2015 18:23:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple; d=etorok.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=ml; bh=N9NrKGW+ssLwbP xX1xsVzHC3fH0=; b=h+Uh8KJtx+oFrl/HJkOt146BEemzGuRVnS4JzkzNuHAhnu cHyykaKCQX/n+PoVyQtI04WyDCSrsB05LJikC86gdFbQK+h+jUYJZgmvY2E8gkcA E4ZyUcJBGm3895IQXc3VF7XtUK+VvtvWHARuzvGvyl3eak9Zm9MMQ7QLm2pxs= DomainKey-Signature: a=rsa-sha1; c=simple; d=etorok.net; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=ml; b=FCnJLSbo 9ZE/L72+wPT5aH6/WRf+BTfR4VSpyZc8SAB6o0jREcZtH5HsGzSybuY7iBNrAoXS NKRzFqFWyILGDyN1L3c6BokwOdzGZRG2VwD2a/49/yXcbyANw9gi4A3V0JLuviSx YqYxTwYTwP+1+9tvCdF4ldLS2FMoYcGrgQs= Received: by mail.etorok.net (OpenSMTPD) with ESMTPSA id 030b46aa TLS version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO for ; Wed, 25 Nov 2015 18:23:21 +0000 (UTC) Message-ID: <5655FCA9.9020506@etorok.net> Date: Wed, 25 Nov 2015 20:23:37 +0200 From: =?windows-1252?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <5655AE66.6000307@coherentgraphics.co.uk> <67E3C8E6-47E2-4010-9399-F66A18EBF493@yahoo.com> (sfid-20151125_185239_422211_47BD5D78) In-Reply-To: (sfid-20151125_185239_422211_47BD5D78) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] Do you use a debugger with OCaml? If not, why not? On 11/25/2015 06:52 PM, Michael Grünewald wrote: > >> On 25 Nov 2015, at 17:16, Anton Bachin wrote: >> >> I always use prints and never debuggers when I have access to the >> source, in any language. I use debuggers when reverse-engineering >> binaries, however. As for why – setting up breakpoints, trying to >> examine values usually takes more time for me than adding some >> prints and reading and understanding the resulting trace. Perhaps >> it only seems that way, but that has been my habit for a very long >> time. > > [ ... ] > > Instead of print-peppering, I prefer to use structured failures > (like the success monad https://github.com/michipili/lemonade) > giving context for the failure, or improved logging capacities. I use tools that I am familiar with when debugging because I don't want to focus on two things (learning a new tool and tracking down/fixing a bug). For Lwt what helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception will have some context and helps towards creating a reproducible testcase. I'd love to be able to use ocamldebug's functionality, but all my OCaml programs are compiled to native code which rules ocamldebug out for the moment. Ideally I'd like to have something like http://rr-project.org/, unfortunately that doesn't work on my CPU (yet). Additional logging is my preferred method too: sometimes I just add a printf, but often it is Lwt.log hidden behind a --debug flag, and I keep these even after the bug is fixed. I also try to turn debug/verbose mode of libraries (OCamlNet, Ocsigen, ..) where possible. Often all I know about a problem is a warning or exception logged long ago, and if its Lwt then the stacktrace usually stops at map or some other uninteresting function, which makes it hard to find the real origin of a bug. What helps is to add certain "labels" to a stack at well-known phases in the code (for example the HTTP method and URL as soon as request processing starts using Lwt.key), then the warning/exception will have some context and helps towards creating a reproducible testcase. Once there is a testcase it is sometimes enough to observe the inputs/outputs using wireshark, sometimes more debugging has to be added. The hardest ones to debug are probably bugs where timing matters (timeouts, intentional retry delays, etc.). I would say this is exactly the way I'm debugging C multi-process/multi-threaded server applications too, not necessarily an efficient one though. Some colleagues always use gdb on C code, but I find grepping logfiles more efficient. For hard to reproduce bugs you can turn on debug mode - even on quasi-production servers for brief periods of time - , and analyze the logs later (quite likely few GB). I haven't spent much time debugging single applications that are not networked, but when I'm writing new code/new module I usually just use utop (either directly or from (Spac)Emacs). There is one case that requires a different debugging technique: SIGSEGV (quite rare, but quite time consuming to track down). Then I use gdb to get a stacktrace, it is almost certainly a bug in C code. Debugging it is similar to the approach I take when debugging incorrect code generated by C compilers (I had quite a few of these in C applications, more than bugs I had in C code linked with OCaml apps). That is: build with debugging aids (in this case OCaml's debug runtime and Gc.compact called often), try to find a reproducible testcase, and then try to minimize the testcase (either manually or via tools like delta.tigris.org). Often this means adding additional sanity checks to the C code being debugged. Once there is a testcase of reasonable size then there is usually enough information to fix it or report to upstream bugtracker. Unfortunately C debugging aids like address sanitizer or valgrind are not easily usable with OCaml C runtime/bindings, because they would only detect corruption at the C level, and wouldn't always detect when C code corrupts OCaml's heap. -- Edwin Török | Co-founder and Lead Developer Skylable open-source object storage: reliable, fast, secure http://www.skylable.com