Date: Tue, 31 Oct 2000 10:54:01 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Tim Nicholson 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.