From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p8TG3NjB008607
	for <caml-list@sympa-roc.inria.fr>; Thu, 29 Sep 2011 18:03:23 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQDAF6VhE4SCRkNm2dsb2JhbABBmVSOOxQBAQEBAQgJCwkUJYIBoyGWXIkBhxMEpSw
X-IronPort-AV: E=Sophos;i="4.68,462,1312149600"; 
   d="scan'208";a="122173383"
Received: from dmz-mailsec-scanner-2.mit.edu ([18.9.25.13])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 29 Sep 2011 18:03:17 +0200
X-AuditID: 1209190d-b7f946d000000966-84-4e8496c49450
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])
	by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 67.D0.02406.4C6948E4; Thu, 29 Sep 2011 12:03:16 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
	by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id p8TG3GCo030142
	for <caml-list@inria.fr>; Thu, 29 Sep 2011 12:03:16 -0400
Received: from localhost (CONTENTS-VNDER-PRESSVRE.MIT.EDU [18.9.64.11])
	(authenticated bits=0)
        (User authenticated as jfc@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8TG3FBX006930
	for <caml-list@inria.fr>; Thu, 29 Sep 2011 12:03:16 -0400 (EDT)
Message-Id: <201109291603.p8TG3FBX006930@outgoing.mit.edu>
To: caml-list@inria.fr
X-Mailer: MH-E 8.2; nmh 1.3; GNU Emacs 23.1.1
Date: Thu, 29 Sep 2011 12:03:15 -0400
From: John Carr <jfc@mit.edu>
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IR4hRV1j0yrcXPoOGBqcWnHRtYHBg9Jr04
	xBLAGMVlk5Kak1mWWqRvl8CV8WKZcsESgYovW0+wNzBe4Oli5OSQEDCR6Jn5gRXCFpO4cG89
	WxcjF4eQwD5GiXNzZjBDOCcZJZbdWsIO4cxkkri2bCVQhoODV8BKYs5xAZBuEaDuWfOvsIDY
	wgK2Eoe//2GGmKor8XHRTHYQm0VAVWLZ8rVgNpuArMSj9i7GCYzcCxgZVjHKpuRW6eYmZuYU
	pybrFicn5uWlFuka6eVmluilppRuYgT7VJJ3B+O7g0qHGAU4GJV4eH8kNfsJsSaWFVfmHmKU
	5GBSEuXdMbXFT4gvKT+lMiOxOCO+qDQntfgQowQHs5IIb1wbUI43JbGyKrUoHyYlzcGiJM5b
	uMPBT0ggPbEkNTs1tSC1CCYrw8GhJMH7DWSoYFFqempFWmZOCUKaiYMTZDgP0PDDIDW8xQWJ
	ucWZ6RD5U4yKUuK8JROBEgIgiYzSPLheWMy9YhQHekWYdxNIOw8wXuG6XwENZgIa/LWwEWRw
	SSJCSqqBse/pN3ERkeMsu67PNWHlrDvb0H12pcNDSRlLrzQno11brwcdXTbxT8Yfyy+Zpbt/
	J8b4tBofu9T9vKp+fZ1pI5+4+o1a3QOXD7NptMzbnLctnqN5nmvHAoVd9fpHq/2fsn7+Gbso
	4HZb1cnzfWvO2K7dueMgn6aRin2HzOQfog07WiR3nt/VrsRSnJFoqMVcVJwIAHe5ayGUAgAA
Subject: [Caml-list] Strange crash after switching to first class modules


One sentence summary: I added a local module generated by
functor application to an unpacked first class module and
the runtime blew up.

My program segfaults in the OCaml runtime whether compiled with ocamlc
or ocamlopt.  I am not using any constructs I know to be unsafe and I am
not linking C code except for the OCaml runtime.

The proximate cause is a bad channel object passed to caml_ml_output.
It does not point to a valid struct channel.  The bad channel is
supposed to be stdout or stderr.  It is neither.  The channel objects
corresponding to stdout and stderr are still valid.

GC is not responsible.  The crash is consistent regardless of changes to
input data size or minor heap size.

This started after I rewrote part of my program to use first class
modules.  The latest svn version "3.13.0+dev7 (2011-09-22)" fails
exactly the same way.

The last module code I added was a local module generated by applying
a functor to a module argument, like

	let solve (type z) problem =
	  let module CHash = Hashtbl.Make((val problem.cmod : C with type t = z) in
	  ...

(The need for the type parameter is annoying.  In context it could
easily be deduced by the compiler.  Maybe there's a more complicated
example where typing is undecidable without hints.)

The last active code in my source is a function that looks like this
in relevant part:

	let format chan x =
	  let f = Printf.fprintf chan "%s %d" in
	    begin match x with
	      | W (n,false) -> f "string" n
	    end

Note the partial application of fprintf.   I raised an exception from
caml_ml_output and the stack trace points to printf.ml:611, which is

    and cont_s n s i =
      outs out s; doprn n i

The bytecode instruction that fails is C_CALL4 calling caml_ml_output
with a bad channel, a good string, start=0, length=9.

The channel argument is in the young heap (caml_page_table_lookup = 2)
and has tag word 0xb00 (tag=0, color=3, size=2).

Any advice on debugging this?

I can't share full source code but I can try to cut down the program.