ftp.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/04/03/16:30:36

X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Message-ID: <3CAB71AB.3060807@vif.com>
From: Sahab Yazdani <sahaby AT vif DOT com>
Organization: PheonixSoft Interactive
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020328
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DOS/Windows Pointer Corruption
References: <3CAA5C53 DOT 6020805 AT vif DOT com> <3CAA9C0E DOT 24631B8C AT is DOT elta DOT co DOT il>
Cache-Post-Path: www.vif.com!unknown AT ip216-239-69-250 DOT vif DOT net
X-Cache: nntpcache 2.4.0b4 (see http://www.nntpcache.org/)
Lines: 69
NNTP-Posting-Date: Wed, 03 Apr 2002 15:21:14 CST
X-Trace: sv3-7x25umBIowHffMbphZMP2/ZPHHFFrypl+QnJfF4N8HyOerp/GWQwgA4Olsy0Gp0fFuRnEi+0z8y+eyB!QOd3VnrwCi5en6rfNjuBVR5g0aoiTxkEk6M18AMYfWupxkXf1LxorwE=
X-Complaints-To: abuse AT GigaNews DOT Com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-Info: Please be sure to forward a copy of ALL headers
X-Abuse-Info: Otherwise we will be unable to process your complaint properly
Date: Wed, 03 Apr 2002 21:21:15 GMT
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


> Doesn't the VESA initialization function returns a pointer in conventional
> memory?  If so, you cannot use memset with it, unless you enable near
> pointers and add __djgpp_conventional_base to the pointer VESA returns.

i *do* add __djgpp_conventional_base as it wouldn't work in either DOS 
or windows if I didn't (also using this line to enable near pointers:
int _crt0_startup_flags = _CRT0_FLAG_NEARPTR | _CRT0_FLAG_NONMOVE_SBRK; )

> Also, what size is the memory region set up by the VESA function, and what
> is the value of width*height*bitDepth?

well I am finding a 640X480 by 8 bit screen (standard mode 0x101), and 
width*height*bitDepth>>3 is 921600 bytes.  but I don't think that VESA 
gives the actual size of the memory region, and that this *is* the way 
to calculate it).

>>PS.  why doesn't symify give line numbers on a traceback anymore??
> Didn't you just say that you were able to find the offending line via
> symify?  How did you do that if it doesn't show line numbers?

well it still gives names of functions and the function that calls 
memset is actually just a one line function called ClearScreen, so when 
I get a traceback like
memset (with some letters attached b4 and after it)
ClearScreen (same as above)
bar (same as above)
foo (same as above)

i automatically assume that that is the *exact* offending line, or am I 
smoking something?.

>>still gives function names (although mangled up cuz of C++) and
>>filenames, but the line number is always 0 now.  i guess it has
>>something to do with my upgrading to GCC 3.0.3?
> No, symify works just fine with GCC 3.0.3 (and 3.0.4), I use it all the
> time.  Does the problem happens in C programs as well, or only C++
> programs?  Can you show a simple program on which symify doesn't work?

i really only work exclusively in C++, but I have a couple C modules 
that I link in with my program and when the crash is in them, it still 
gives the line as 0, but this might be completely different....

i tried making some very primative code that shows this, but symify 
managed to give line numbers, but I will keep my eyes open...

thank you very much for your help BTW.

* Sahab Yazdani * "Lisa, in this house we obey the laws of   *
* Thornhill S.S * thermodynamics!" - Homer Simpson           *
* http://pheonixsoft.virtualave.net/                    * :) *

- Raw text -

  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019