X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f From: Jim Michaels Newsgroups: comp.os.msdos.djgpp Subject: Re: issue with 4.5.3 beta, 4.5.2 beta Date: Mon, 23 May 2011 03:26:40 -0700 (PDT) Organization: http://groups.google.com Lines: 86 Message-ID: <688c7223-001d-4b8b-9f25-145099987925@s16g2000prf.googlegroups.com> References: <1b5aeeeb-ffaa-42ce-88c4-ec8773bcceef AT j13g2000pro DOT googlegroups DOT com> <572246ce-db12-406b-a5da-1fa4272e10e9 AT 17g2000prr DOT googlegroups DOT com> NNTP-Posting-Host: 24.22.56.37 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1306146400 20466 127.0.0.1 (23 May 2011 10:26:40 GMT) X-Complaints-To: groups-abuse AT google DOT com NNTP-Posting-Date: Mon, 23 May 2011 10:26:40 +0000 (UTC) Complaints-To: groups-abuse AT google DOT com Injection-Info: s16g2000prf.googlegroups.com; posting-host=24.22.56.37; posting-account=05hOMwoAAAB6R8xtiQKzEljSMzgOhVF1 User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1,gzip(gfe) Bytes: 4688 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On May 23, 12:23=A0am, Eli Zaretskii wrote: > > From: Jim Michaels > > Newsgroups: comp.os.msdos.djgpp > > Date: Sun, 22 May 2011 21:45:37 -0700 (PDT) > > > On May 22, 9:30=A0pm, Jim Michaels wrote: > > > I have a program and small library that I recently worked the bugs ou= t > > > of to my best understanding. > > > I included a lot of debug output using #if defined(_DEBUG). > > > that debug ouput is flushed at every instance. > > > the library output shows with -g compiler switch, but not without. > > > the main program's debug output always shows. > > > > can someone explain this? =A0I have the #define on in both the librar= y > > > file and the main source and the header file. > > > I think I am running into a compiler bug. > > > > and this doesn't happen with mingw-w64 (a gnu compiler for windows). > > > I should mention, the program throws a SIGSEGV or SIGILL if I execute > > the program my normal way (with debug symbols stripped out with -s) > > and only 1 argument is partially processed and dies as soon as it hits > > the library. > > with -g, works perfect. > > Does the problem go away if you compile with another version of GCC, > but still in the DJGPP environment (as opposed to MinGW)? no. the only djgpp compilers which happen to have even a part of TR1 is the betas. neither works. I did have some new spots where there were some returns without a free(), but I fixed those and I still have the problem. Mon 05/23/2011 2:26:24.60|C:\prj\buildnum\BUILDN~1.0\dos|>call test Mon 05/23/2011 2:26:24.62|C:\prj\buildnum\BUILDN~1.0\dos|>. \buildnum.exe -bat phone -txt buildnm -cmd laramie Exiting due to signal SIGSEGV Stack Fault at eip=3D00004a88 eax=3D0004e7dd ebx=3D0009e810 ecx=3D0008e7d3 edx=3D0004e7d1 esi=3D00000054 edi=3D0001e840 ebp=3D0003e7b8 esp=3Dffffe744 program=3DC:\PRJ\BUILDNUM\BUILDN~1.0\DOS \BUILDNUM.EXE cs: sel=3D01af base=3D02990000 limit=3D000affff ds: sel=3D01b7 base=3D02990000 limit=3D000affff es: sel=3D01b7 base=3D02990000 limit=3D000affff fs: sel=3D017f base=3D00006100 limit=3D0000ffff gs: sel=3D01bf base=3D00000000 limit=3D0010ffff ss: sel=3D01b7 base=3D02990000 limit=3D000affff App stack: [0009e840..0001e840] Exceptn stack: [0001e750..0001c810] Call frame traceback EIPs: 0x00004a88 Mon 05/23/2011 2:26:24.67|C:\prj\buildnum\BUILDN~1.0\dos|>type _buildnm.txt 1792 Mon 05/23/2011 2:26:24.67|C:\prj\buildnum\BUILDN~1.0\dos|>type set_laramie_buildnumber.cmd @set _laramie_buildnumber=3D3 Mon 05/23/2011 2:26:24.67|C:\prj\buildnum\BUILDN~1.0\dos|>type _phone.bat @set _phone=3D21 Mon 05/23/2011 2:26:24.67|C:\prj\buildnum\BUILDN~1.0\dos|> the clue was the stack fault. I googled it, and found this: http://www.delorie.com/djgpp/v2faq/faq15_9.html I had 4 strings on the stack which were statically allocated as 65535 bytes each (char s[65535]) in my library function. I have since switched this out for more secure malloc. things are working much better. (I think I had better switch to calloc for more security). ...And mainly since I don't know the size of the strings that this function is going to get. the code works now, whatever switches I try. thanks for your time. the compiler REALLY needs a bigger stack. only 512K (acts like 128K)? really now... most systems have 8GB RAM.