delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/10/31/05:45:28

Date: Tue, 31 Oct 2000 10:54:01 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Tim Nicholson <djgpp_mail AT gizzy DOT co DOT uk>
cc: djgpp AT delorie DOT com
Subject: Re: SIGSEGV page fault DOS but not Windows
In-Reply-To: <8tlt8t$p3$1@neptunium.btinternet.com>
Message-ID: <Pine.SUN.3.91.1001031104445.24533I-100000@is>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

On Tue, 31 Oct 2000, Tim Nicholson wrote:

> My pointer is to a static array not a dynamic array. Although I accept that
> there may be a bug, this would not explain why, when it works under windows,
> the correct labels are always displayed

If you reference an invalid address just to test something, Windows 
returns you some garbled value, which might pass the test by sheer luck.  
In contrast, on plain DOS, accessing the invalid address will crash the 
program before you get to do the test.

> As button_label is a static array of constants and x and setup->language are
> always in range, I cannot see how the pointer can be invalid.

Are you sure setup->language is always in range?  Did you check that?

Also, from what little did you say about the code, I think it's 
possible that you access the array incorrectly, where you treat it as 
several subarrays.  Posting the line that crashes and the declarations of 
the variables involved would have helped here.

> As I said, it would seem that part of the static array is becoming
> unallocated (as opposed to not being allocated in the first place)

This simply cannot happen.

> I will try your suggestion though, just in case.

Yes, please do.  Charles generally knows what he is talking about, when 
these issues are involved ;-)

Please also note that section 12.2 of the DJGPP FAQ list explains quite a 
lot about the crash message printed by DJGPP programs, and how to debug 
the various problems using the info in the crash message (which you 
should have posted here, btw).

Finally, running your program under a debugger on a DOS machine would 
pinpoint the place where it crashes, and you could then poke around 
looking at the variables involved in the line that caused the crash.  
Ultimately, this is *the* way to hunt down bugs; looking at the source 
will not help, more often than not.

- Raw text -


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