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: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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