From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 86190BC0C for ; Thu, 18 Jan 2007 09:14:30 +0100 (CET) Received: from smtp.irisa.fr (smtp.irisa.fr [131.254.254.26]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l0I8EU3N032513 for ; Thu, 18 Jan 2007 09:14:30 +0100 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 20611FA92; Thu, 18 Jan 2007 09:14:29 +0100 (CET) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31479-02; Thu, 18 Jan 2007 09:14:27 +0100 (CET) Received: from [131.254.10.144] (polaris.irisa.fr [131.254.10.144]) by smtp.irisa.fr (Postfix) with ESMTP id 014F6FAA3; Thu, 18 Jan 2007 09:14:27 +0100 (CET) Message-ID: <45AF2C62.8080906@irisa.fr> Date: Thu, 18 Jan 2007 09:14:26 +0100 From: Sebastien Ferre Organization: IRISA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: caml-list@yquem.inria.fr Cc: Olivier Andrieu , =?ISO-8859-1?Q?Daniel_B=FCnzl?= =?ISO-8859-1?Q?i?= Subject: Re: [Caml-list] marshaling limits References: <2a1a1a0c0701161248l5a1d9ad9q739da9c593fc5219@mail.gmail.com> <45ADE8FE.5070004@irisa.fr> <45AE41C7.8080409@univ-paris12.fr> <45AE43A9.3090904@irisa.fr> <95513600701170832j30a8b0b3h9a0f0a25a8bd4f8c@mail.gmail.com> In-Reply-To: <95513600701170832j30a8b0b3h9a0f0a25a8bd4f8c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Miltered: at concorde with ID 45AF2C66.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; irisa:01 marshaling:01 andrieu:01 bunzli:01 buenzli:01 bytecode:01 segfaults:01 marshalling:01 stack:01 recursion:01 stack:01 bytecode:01 marshaled:01 wrote:01 wrote:01 Olivier Andrieu wrote: > On 1/17/07, Daniel Bünzli wrote: > >> >> Le 17 janv. 07 à 16:41, Sebastien Ferre a écrit : >> >> > pourtant, je passe bien par un appel a output_value >> > dans un fichier, sans passer par une chaine intermediaire. >> >> Maybe output_value uses a string internally. Try with a bytecode >> version of your executable, an exception should be raised (or have a >> look at the implementaiton of output_value). > If it segfaults, that's most probably because the marshalling runs out > of executable stack (because of too much recursion). I've seen it do > this before. The "fix" is to increase the maximum size of the > executable stack. Indeed, you're right. I could solve the problem by using the 'ulimit -s' command. > The behavior is the same with bytecode or native code since it's not > the interpreter's stack that overflows, it's the C one. I didn't know the existence of this C stack. How can I have an idea of the necessary size ? Is it related to the depth of data structures to be marshaled ? Thanks ! Sébastien