From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id 91E97BC57 for ; Tue, 30 Mar 2010 09:14:34 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnECAA5CsUtKfVwZkGdsb2JhbACPFYF1ihoIFQEBAQEJCQwHEQMfr3mBaYU/LYhMAQEDBYR7BIMf X-IronPort-AV: E=Sophos;i="4.51,333,1267398000"; d="scan'208";a="56151843" Received: from qw-out-2122.google.com ([74.125.92.25]) by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Mar 2010 09:14:34 +0200 Received: by qw-out-2122.google.com with SMTP id 8so3241292qwh.15 for ; Tue, 30 Mar 2010 00:14:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type; bh=mCq4IQhXDhbEnx5t/JNRbk5JLFA8H8zfEZvynnHFshA=; b=pvLNUMPNHkAzab5U+XTSnR/mSrt92NDaUfW3UsJZzWCV2WVKGZnNepqCZ4bDkZEKO/ sXs1RW7Evp/jTrFYcsnYVe+oxIVUozf+IHVVnBEgQi5yL4tiq3/A7ZOAldcmq5Bh4Ijp QhGWJRvmCVsypzslVo5m3v3BNCMjwwNVLyTJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=ImrcG1eMXXhYQsrsNkrJO58QS1OCJhWYdHZ5Ttt8UQWJLljJ0J9ElgM/TJLp7KG2Oi Wlll+COsg/7QKx5EX96Y+2q2r2KOwJ+QAhN3F0Qoj2FSzSURo7W7pGURGtiX8ZNy/j0t 4t1vnhf5y6EOeBgCf/CrtI9PETkABU1a5Fo0w= MIME-Version: 1.0 Received: by 10.229.231.17 with HTTP; Tue, 30 Mar 2010 00:14:32 -0700 (PDT) Reply-To: david.baelde@ens-lyon.org In-Reply-To: <874okd2907.fsf@frosties.localdomain> References: <87wrxb5p59.fsf@frosties.localdomain> <20100317083907.GC26002@janestreet.com> <87sk7zgtpq.fsf@frosties.localdomain> <87hboehphv.fsf_-_@frosties.localdomain> <874okd2907.fsf@frosties.localdomain> Date: Tue, 30 Mar 2010 01:14:32 -0600 Received: by 10.229.88.193 with SMTP id b1mr1217330qcm.27.1269933272508; Tue, 30 Mar 2010 00:14:32 -0700 (PDT) Message-ID: <53c655921003300014s2c7b05eax24b91edbb0d0d9ec@mail.gmail.com> Subject: Re: [Caml-list] Re: Random segfaults / out of memory From: David Baelde To: Goswin von Brederlow Cc: Caml Mailing List , "Savonet's developpers list" Content-Type: text/plain; charset=ISO-8859-1 X-Spam: no; 0.00; segfaults:01 bigarray:01 alloc:01 bug:01 bigarrays:01 cheers:01 wrote:01 caml-list:01 functions:01 functions:01 caml:02 roots:02 seems:03 tricky:04 stream:04 On Thu, Mar 18, 2010 at 4:56 AM, Goswin von Brederlow wrote: > This is a tricky situation. The md5_update_bigarray() on its own is a > "noalloc" function. But due to the caml_enter_blocking_section() another > thread can alloc and trigger a GC run in parallel. So I guess that makes > the function actually not "noalloc". Thanks for reporting about your experience! This made me suspect noalloc in a bug of mine, and indeed removing a bunch of noalloc did the trick. Now I'd like to understand. Unlike in your example, global roots were registered for the bigarrays in "my" functions. This should avoid that they are freed when the global lock is released. Still, noalloc seems wrong with those functions. I'm not sure yet which function is problematic in my case, but they all follow the same scheme, see for example . So, is it really forbidden to release the global lock in a noalloc function? Cheers, -- David