X-Recipient: archive-cygwin@delorie.com X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,SPF_HELO_PASS,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org Message-ID: <28998473.post@talk.nabble.com> Date: Fri, 25 Jun 2010 21:32:12 -0700 (PDT) From: mredekopp To: cygwin@cygwin.com Subject: Re: False alarm about exception C0000005 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable References: <4BFC92B1.2020500@gmail.com> X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com Hi all I saw this thread when searching for a similar error I'm getting. Mine is not with large binaries, but with lots of memory allocations (I'm doing some processing on a large IC netlist). When my program reaches around 800 MB of memory or so it will crash. I tried to use GDB but it just gave me code C0000005 and nothing to locate the problem. I tried to catch a failed memory allocation using a std::bad_alloc exception but it doesn't seem to get thrown. I'm using cygwin 1007.5.0 on Vista 32-bit Enterprise... Any ideas about this? Thanks M Magnus Reftel wrote: >=20 > On 26 May 2010 05:17, Dave Korn wrote: >> On 25/05/2010 12:47, Magnus Reftel wrote: >>> Hi all, >>> >>> I discovered that the problem does not only affect Cygwin. It was just >>> that I did not have any large binaries outside cygwin. Large >>> executables built using VS Express also crash with the same exception. >>> I guess the =C2=A0IT department installed some broken crap on our machi= nes >>> again. Sorry for the confusion! >> >> =C2=A0I had just about reached the same conclusion. =C2=A0The limit to an >> executable >> size on my machine was somewhere between 542048077 and 542048589 bytes, >> and >> the only failure mode I observed was a proper error message from bash: >> >>> $ ./big.exe >>> bash: ./big.exe: Cannot allocate memory >> >> =C2=A0So, I reckon you probably have some interfering BLODA, maybe a DLL= that >> is >> injected into all processes and tries to allocate some memory at startup >> or >> something like that and doesn't handle a failure well. >=20 > That seems to be correct. In the failing case (when compiled with VS), > the VS debugger lists ntdll.dll and kernel32.dll being loaded before > the crash, and when the executable does not crash, sysfer.dll and > msvcr100d.dll are also loaded. sysfer is a Symantec DLL. Should have > guessed it... >=20 > Anyway, thanks for looking at this and sorry to have wasted your time! >=20 > Best Regards > Magnus Reftel >=20 > -- > Problem reports: http://cygwin.com/problems.html > FAQ: http://cygwin.com/faq/ > Documentation: http://cygwin.com/docs.html > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple >=20 >=20 >=20 --=20 View this message in context: http://old.nabble.com/False-alarm-about-excep= tion-C0000005-tp28667376p28998473.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple