From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 5F2F5BC57 for ; Wed, 9 Jun 2010 20:24:33 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloCALJ4D0xKfVO0kGdsb2JhbACeSQgVAQEBAQkJDAcRAx+IGaZ6ggOFQi6ITwEBAwWFEwSDSQ X-IronPort-AV: E=Sophos;i="4.53,393,1272837600"; d="scan'208";a="52767612" Received: from mail-pv0-f180.google.com ([74.125.83.180]) by mail2-smtp-roc.national.inria.fr with ESMTP; 09 Jun 2010 20:24:32 +0200 Received: by pvg7 with SMTP id 7so2616074pvg.39 for ; Wed, 09 Jun 2010 11:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=eJCIaqEJ4GjyKu8wlQ1RAMLS1mLqkHVJcUQs/pLzvRA=; b=s2nD8TKH7tRgt+A1MCXGf/GDWrav37IvPqeoO774u5uquEbSUTK6WSZ0UUIWEI+MnR QtW8hgIej5ArVzsxbMgqw5W/yalAanL24Y2zq9oDM6yFeo7Kx8KRaGTvomQ04mAc/45+ SYlqrxs9t3kuMPSmkbX23Nt8QePVY/gXpR7+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=DyBX8O9hAfpj65nytTdIIcTodEgrk9JKtG8sBNAKvdHC5wiYzV6OcQnnSMiw6hC1nS ceYjW2HwNiqhKifcAz3SBItijJ7GGrtwKyRI7j5GDVVxhwz6YnvyM5FTEa+tBv0zrbf1 EK52Pm6R0UtpFo+Guy5iNhit4Mpd/t+fqnuTk= Received: by 10.140.87.40 with SMTP id k40mr14825999rvb.251.1276107871373; Wed, 09 Jun 2010 11:24:31 -0700 (PDT) Received: from [192.168.0.34] (c-24-5-88-93.hsd1.ca.comcast.net [24.5.88.93]) by mx.google.com with ESMTPS id g14sm6954189rvb.1.2010.06.09.11.24.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Jun 2010 11:24:30 -0700 (PDT) From: Warren Harris Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: gc crash Date: Wed, 9 Jun 2010 11:24:28 -0700 Message-Id: <36309832-BCEF-4169-BCDB-53182335DFEC@gmail.com> To: caml-list caml-list Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) X-Spam: no; 0.00; ocaml:01 freelist:01 freelist:01 gdb:01 alloc:01 wosize:01 oldify:01 oldify:01 dfb:01 ocaml:01 gcc:01 bug:01 bug:01 hashtbl:01 hashtable:01 I've observed the following gc crash with my ocaml (3.11.2) application, = after attempting to implement a memory-flushing routine with = Gc.create_alarm: Program received signal SIGSEGV, Segmentation fault. 0x00000000007c15a7 in caml_fl_allocate (wo_sz=3D) = at freelist.c:171 171 freelist.c: No such file or directory. in freelist.c (gdb) bt #0 0x00000000007c15a7 in caml_fl_allocate (wo_sz=3D) at freelist.c:171 #1 0x00000000007c33f9 in caml_alloc_shr (wosize=3D5, tag=3D247) at = memory.c:409 #2 0x00000000007c2628 in caml_oldify_one (v=3D140737353752592, = p=3D0x7fffff400f08) at minor_gc.c:130 #3 0x00000000007c02d3 in caml_oldify_local_roots () at roots.c:203 #4 0x00000000007c2840 in caml_empty_minor_heap () at minor_gc.c:229 #5 0x00000000007c2969 in caml_minor_collection () at minor_gc.c:272 #6 0x00000000007c0e51 in caml_garbage_collection () at signals_asm.c:68 #7 0x00000000007cfc32 in caml_call_gc () #8 0x4178dfb350000000 in ?? () #9 0x41d303f4a85a6a55 in ?? () #10 0x40f2eddb4aeeae5c in ?? () #11 0x4171af416ff5f186 in ?? () #12 0x40ede93d997081cb in ?? () #13 0x3e1460aa5c6654d8 in ?? () #14 0x3e2318142703c7d0 in ?? () #15 0x4170000000000000 in ?? () #16 0x0000000000000000 in ?? () I rebuild ocaml with gcc -g to get this much information. My process = grows to about 57MB before the crash occurs. I don't think it's an = out-of-memory condition, because the app would grow to many GB before = the memory flushing change was added. Unfortunately, my attempts to = reproduce the problem with a small test case have failed so far (my app = is rather large and uses ocsigen and lwt). Perhaps the problem relates to the fact that my memory flusher iterates = through some large Hashtbls acting as a cache, removing entries in order = to reduce the footprint. (Note that this seems very similar to the bug = described here: = http://caml.inria.fr/mantis/print_bug_page.php?bug_id=3D2893 although I = can't reproduce that specific problem either.) My questions are: - what is the best way to debug this problem? - is it safe to call Hashtbl.remove from within Hashtable.iter and/or a = gc alarm? - is there a better way to be notified of memory pressure, or to build a = cache in general? -- I've considered weak hashtables, but route seems to = require another table to prevent all entries from being evacuated during = gc (I don't want to rely exclusively on roots from active transactions = within my app to prevent uncaching.) Thanks for any help on these issues, Warren