From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by hurricane.the-brannons.com (Postfix) with ESMTP id 4B84F78425 for ; Thu, 6 Feb 2014 22:31:24 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id PJTP1n0061HzFnQ59JWpLP; Fri, 07 Feb 2014 06:30:49 +0000 Received: from eklhad ([107.5.36.150]) by omta14.westchester.pa.mail.comcast.net with comcast id PJWp1n00F3EMmQj3aJWpZ0; Fri, 07 Feb 2014 06:30:49 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Fri, 07 Feb 2014 01:30:51 -0500 Message-ID: <20140107013051.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391754649; bh=h836JlwkahPGjgiLocaoRv40i6iOJwUqIaw6f4V+x/8=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=M0e/C9G3sauGeKzvrVJP27ZrscEckUwJ82H7QXzpiV8A7sijTyE1dGfWF62uFOeCP IPS8zeme+QCZmggzKtmSGogcH+4L8EBMYUlou+YG3nCLUaC7lKgEI8iu8UJaf0Qk1v Ia1da71deTTpC+HlfNIlL8m9B7GEL1N16nRx5+OwOpXV1J54O0zeTvAsTjfzgegEUH xHU2Fq/1ZLCW3yBfigOTmAV2o2HbM69sUAdmABqM937be1u0hDBkJuKnGJTuPaBuTF Et/mF8P5rA8QlBzj/49lomSHPi2Ff2e57xcuuPOWlSedhwHvVTPviC6tjVmZsa9vof Mt8DlTi4hAWSQ== Subject: [Edbrowse-dev] suggest increasing the size argument to JS_NewRuntime X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 06:31:24 -0000 > From what I can tell, the remaining segfaults all seem to be caused by > out-of-memory errors in JS. Really? JS is so bad that when it exhausts its memory pool it segfaults? That doesn't give me a warm fuzzy feeling. Or maybe js returns 0, like any malloc failure, and I don't watch for that and then I segfault. If that is the case then we need to write lots more error legs, which is really tedious programming. Sure, push the run time memory up to 32 or 64 meg. Why not? Probably can't buy a computer these days with under 4 gig, or even a smart phone. But that doesn't explain why Chris simple program segfaults on debian js. > As an aside, with debug level 2 or greater, > edbrowse will print "out of memory" before it crashes. Not sure what this means. My wrappers around malloc do indeed print and exit upon malloc failure, which probably saves me about 3,000 lines of error leg programming, but you don't need debug levels, it just happens. However ... on a 64 bit machine with lots of memory, integers could overflow before we are out of ram. Even though it's a signed int, malloc prototype is size_t, which is unsigned, so we're really good all the way up to unsigned in, however, beyond that we are allocating a really small number, instead of 4 gig, and then we tromp over unallocated memory, and that's bad. Remember that edbrowse was originally written when the best computer on the market had 64 meg. So I need to revamp all these strings and allocated arrays, and use size_t, and then for the 32 bit machines, make sure there is no size_t overflow. A file with half a billion lines, times sizeof(struct lineMap), goes over the limit. Plenty to think about here, but perhaps more important is putting in more dom objects and functions to support more websites. But we should probably remain focused on js 24 and the next release. Thank you so much for all your help and hard work. Karl Dahlke