From: SMTP%"janb@pmatrix.com" 11-OCT-1997 10:47:26.32 To: erics@picksys.com, ntdev@atria.com CC: Subj: Re: App crashes mystery Return-Path: owner-ntdev@atria.com Received: by arisia.gce.com (UCX V4.1-12C, OpenVMS V7.1 VAX); Sat, 11 Oct 1997 10:38:41 -0400 Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by bort.mv.net (8.8.5/mem-951016) with SMTP id GAA29914 for ; Fri, 10 Oct 1997 06:40:58 -0400 (EDT) Received: by gw.atria.com id Fri, 10 Oct 1997 00:37:45 -0400 Received: from ns1.pmatrix.com by gw.atria.com id Fri, 10 Oct 1997 00:37:41 -0400 Received: from beth (ppp-206-170-30-6.hywr01.pacbell.net [206.170.30.6]) by ns1.pmatrix.com (8.7.6/8.7.3) with SMTP id VAA18933; Thu, 9 Oct 1997 21:42:24 -0700 Message-Id: <3.0.3.32.19971009213719.030b82e0@mailhost.pmatrix.com> X-Sender: janb@mailhost.pmatrix.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 09 Oct 1997 21:37:19 -0700 To: erics@picksys.com, ntdev@atria.com From: Jan Bottorff Subject: Re: App crashes mystery In-Reply-To: <343D60FF.1A68@picksys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ntdev@atria.com Precedence: bulk There may be an easy answer. The MSVC 4.2 (and all previous versions) run-time library has a bug in it's heap error handling. For example, if you say (using VC 4.2): foo = malloc(1000000000); // allocate a billion bytes The app will just go poof. No messages of any kind. The reason for this is Microsoft changed the return codes for VirtualAlloc starting in NT 3.51. The MSVC run-time checks for specific return codes for VirtualAlloc and calls ExitProcess if it's not one it knows about. If you run out of swap space, you get an error that means out of swap space under NT 3.51, which is not an error MSVC knew about under NT 3.5. If you look at the run-time source for malloc, you'll see where this all happens. It's anytime the run-time thinks something is wrong with the heap. Actual heap corruption can cause this too. I think console apps printed a message that said something about heap corruption. I don't believe any fix was ever released. The MS answer was use MSVC 5.0. I know MANY apps built with pre-5.0 MSVC have this problem. I can remember reading product reviews where this would happen (like a major magazine's review of NT web servers). They said Netscape's web server was unstable and sometimes just went poof. The truth is Microsoft's language group was unwilling to release a patch for a bug that caused many program failures and the OS group was unwilling to release a patch to make the return codes like they were in NT 3.5. I think my personal confidence of NT as a viable OS was significantly downgraded when I found out the details of this. I sent Microsoft feedback suggesting then needed some sort of versioning of return codes from API's. That is, an app written to expect NT 3.5 valid return codes will not see codes only valid in NT 4.0. The parameters only define part of the behaivor of API's. The return codes, exception info, and side effects also are things an app expects to be a certain way. I think the whole battle over Java conformance is exactly this kind of issue. Microsoft has a proven track record of NOT keeping your apps compatable (bug free compatable) with new OS versions. I for one am a little tired of replacing all my apps every few years because the OS has changed and my fine old apps no longer work correctly. One sortof work around is be sure LOTS of swap space is allocated, like 500 MBytes. - Jan At 03:55 PM 10/9/97 -0700, you wrote: >I have an app which crashes once in a while without any message: no dr >watson, no 'abnormal termination', no 'pure virtual function call >abort', no nothing... The customer is on SP1, but I am going to upgrade >to SP3 asap (they have a dual pp200). Could it be it? ___________________________________________________________________ Paradigm Matrix, San Ramon California "Development services for Win32 platforms" Internet: Jan Bottorff janb@pmatrix.com WWW http://www.pmatrix.com Phone: voice (510) 803-9318 fax (510) 803-9397 PGP: public key fingerprint 52 CB FF 60 91 25 F9 44 6F 87 23 C9 AB 5D 05 F6 ___________________________________________________________________ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ To unsubscribe, send email to ntdev-request@atria.com with body UNSUBSCRIBE (the subject is ignored). ]