From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id BAA18938; Sat, 2 Mar 2002 01:11:47 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id BAA18384 for ; Sat, 2 Mar 2002 01:11:41 +0100 (MET) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g220Beb27366 for ; Sat, 2 Mar 2002 01:11:40 +0100 (MET) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (2302 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 1 Mar 2002 16:11:39 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Date: Fri, 1 Mar 2002 16:11:32 -0800 Subject: Re: [Caml-list] troubleshooting problem related to garbage collection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: The Trade To: james woodyatt From: james woodyatt In-Reply-To: <81A4E362-2D45-11D6-BA3A-000502DB38F5@wetware.com> Message-Id: <0D00592F-2D72-11D6-BA3A-000502DB38F5@wetware.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Friday, March 1, 2002, at 10:52 AM, james woodyatt wrote: > > Last night I spent a lot of time trying to figure out why an assertion > was failing in my code when I use it with large data sets. I'm still > puzzled. > > This morning, I inserted the following at the beginning of my main > module: > >> Gc.set { >> (Gc.get ()) with >> Gc.major_heap_increment = 64000 >> } > > This made the problem go away. Further investigation reveals that it does not make the problem go away, it changes the failure mode into one that only makes it look like the problem has gone away. The process terminates prematurely (but there was no more output expected anyway). > What's even more strange is that there are multiple failure modes to > choose from depending on which number I pick for the > major_heap_increment value. The number I am using here just happens to > be the one that makes the code work. > > Can anyone advise me on how to find the bug here? I've found the problem. It was a function trying too hard not to blit a string. The bug only manifested when writing to a non-blocking TCP socket would return a value less than the number of octets to send. This makes me think that when similar problems arise-- i.e. when changing the parameters of the GC seems to make always-reproduceable misbehavior change in some remarkable way-- the first place to start looking for the cause is code that blits strings. -- j h woodyatt "...the antidote to misinformation is more information, not less." --vinton cerf ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners