X-Authentication-Warning:	delorie.com: mail set sender to djgpp-bounces using -f
From:	Jim Michaels <jmichae3 AT yahoo DOT com>
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> <E1QOPUT-0000ZC-5Q AT fencepost DOT gnu DOT org>
NNTP-Posting-Host:	24.22.56.37
Mime-Version:	1.0
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 <e DOT  DOT  DOT  AT gnu DOT org> wrote:
> > From: Jim Michaels <jmich DOT  DOT  DOT  AT yahoo DOT com>
> > Newsgroups: comp.os.msdos.djgpp
> > Date: Sun, 22 May 2011 21:45:37 -0700 (PDT)
>
> > On May 22, 9:30=A0pm, Jim Michaels <jmich DOT  DOT  DOT  AT yahoo DOT com> 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.

- Raw text -