Mail Archives: djgpp/2000/10/31/02:47:56
There is no malloc!
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 - I'll try to explain better...
The static array contains 500 sets of labels that are displayed on buttons.
It is a three dimensional array:
char button_label_array[500][4][11] = { ".....
In other words there are 500 labels in four languages each up to 10 chars
long.
label, in my program is defined as a char pointer and set like so..
label = &button_label_array[x]; (where x always = 0 to 99).
I pass (*label)[setup->language] to the function. setup->language is always
between 0 and 3 and must be ok otherwise none of the labels would be
displayed (some of them do work in DOS - its the later ones that cause the
page fault)
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.
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)
Sorry if I am being very thick but.....
I will try your suggestion though, just in case.
Tim
"Charles Sandmann" <sandmann AT clio DOT rice DOT edu> wrote in message
news:39fda5a2 DOT sandmann AT clio DOT rice DOT edu...
> > I have a program which runs fine in a Windows 'DOS window' but produces
a
> > page fault when run in true W98 DOS.
>
> ..
>
> > Any ideas on how I can fix this? I have looked at the FAQ and there are
some
> > topics that may be relevant but I am not sure which ones really apply to
> > this problem - I think the problem is more likely to be with CWSDPMI
than
> > DJGPP and I suspect it is to do with the configuration of the server or
> > perhaps EMM386 but I don't know enough about the ins and outs of DMPI
(or
> > PC's generally) to work out how to resolve it!
>
> 1) Get r5
> 2) issue the command cwsdpmi -x before running your program
> 3) run the program
>
> If the problem goes away then this is a null pointer problem (and a bug
> in your program). The -x qualifier (this is a one pass test only)
> disables the 1.0 extensions (and allows Windows developed buggy programs
> to run). You can also permanently disable null pointer checking
> capabilities using cwsparam. This feature was specifically added for
> people who develop under Windows and think ignorance is bliss.
>
> It could be the null pointer is due to a malloc that failed (do you
> check all these?)
>
> Have you checked the amount of memory you see using go32-v2? How does
> this compare to the amount you expect to allocate?
- Raw text -