delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/06/10/04:53:16

X-Authentication-Warning: mail.bio.uva.nl: Host biomacI-159.bio.uva.nl [145.18.167.159] claimed to be [145.18.167.159]
X-Sender: dlanor AT dds DOT nl (Unverified)
Message-Id: <v01540b01b3852d011dfb@[145.18.167.138]>
Mime-Version: 1.0
Date: Thu, 10 Jun 1999 10:55:26 +0200
To: djgpp AT delorie DOT com
From: dlanor AT dds DOT nl (Dlanor Blytkerchan)
Subject: re: malloc() problem
Reply-To: djgpp AT delorie DOT com

>> I'm thinking of going around it
>> by stubifying my program and putting it in pmodstub.exe - if I understand
>> the docs correctly, that should work.
>PMODE should work, but it disables virtual memory.  Since you have a
>memory-starved system, are you sure you want it?
I'd rather not use it, but if it works, I'll just have to go with it..

>> A weird thing is, though, that the
>> test sources I downloaded from simtel for DJGPP, where malloc() is also
>> used without calling CWSDPMI externally first, do work.
>I don't follow.  Which test sources did you donwload, and how are they
>different from what your failing program does.
I downloaded a package containing sources of all kinds of foolish programs.
I don't recall what it was called, but it was described as "test sources"
and unpacked into a directory called DJGPP/TESTS. I have it about 20 miles
from here. I can look it up when I get there (or send it to you, if you
like). I downloaded it from the same directory I downloaded the timezone
stuff from (your suggestion for errno 22 in time(), I decided to download
the stuff anyway, to see how it works).

>> My only remaining
>> idea for the cause of this problem is that malloc simply won't do anything
>> as "large" as 34K from the program I'm writing: trying it with a smaller
>> struct does work.
>`malloc' doesn't care much about the size of the chunk you are
>requesting.  The failure comes from passing the request via `sbrk' to
>the DPMI server and, eventually, to the extended memory manager.
So I gathered. Another weird thing, though: at your request I tried
downsizing the source of the program that produces the error, by allocating
an char array of the same size in stead of the struct I was using (but
leaving everything else, including the typedef, libraries, etc. in place).
The error was gone. Here's the change:

#include a lot of headers (including stdlib.h)
typedef struct {
  34 K of VGAP-related crap
} bufferType;

bool rc = true;
// bufferType *buffer; // old
char *buffer; // new
// some small globals like gamePath and basePath. Altogether about 1 K

int main(void) {
  rc = getCommandLine(); // (a library function used by all my add-ons for VGAP)
//  if (rc) rc = ((buffer = malloc(sizeof(bufferType))) != NULL); // old
  if (rc) rc = ((buffer = malloc(34 * 1024)) != NULL); // new

  return(0);
} // main()

This produces no errors. If I uncomment where I say "// old" and comment
away where I say "// new", the error is produced.
bufferType is actually a concatination of divers structs, which together
form the contents of a database, used for this VGAP add-on. To understand
what this struct is composed of you'd need to know the game and the add-ons
function, but it is rather irrelevant. Suffice it to say there is a sum
total of three levels of struct within this struct:
typedef struct {
} baseStruct;
typedef struct {
  baseStruct crap1;
} firstLevel;
typedef struct {
  firstLevel dcrap2[500];
} secondLevel;
typedef struct {
  secondLevel prr[11];
} bufferType;

As far as I know, this is legal. I.e., I have used it before without any
problem, but with another compiler. My current working hypothesis is that
there is a problem with this anyway. I am currently thinking of simply
ripping the struct apart and allocating it in diffirent variables. Though
the endresult - at least in the database I/O - will much much less elegant,
I think it may be the only option, as I am starting to suspect this is not
all that legal after all..

>> If anyone has some real-life source that does this and does work,
>> preferably ANSI C, but C++ will do as well, I would be much obliged.
>Well, I have a real-life source called ``Emacs'' that allocates gobs
>of memory in chunks that are usually much larger than 34KB, eventually
>stabilizing at [checking] 25MB if I work long enough (this one was
>running for a week without shutting it down), and I never had any
>problems with it.
I've "heard" a lot about this Emacs, just not what it's for ;-)
I'd be interested in taking a look at the source should my current plan de
campagne (which is not quite as much like random violence as I described it
before) fails to produce results. Is it available somewhere (on an FTP
site)?

Greetz!

Dlanor


- Raw text -


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