X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f Message-ID: <3CAB71AB.3060807@vif.com> From: Sahab Yazdani 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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 [snip] > > > 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?. > > >>it >>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/ * :) * **************************************************************