Mail Archives: djgpp/1994/08/25/17:43:55
Thanks for your prompt reply!
> Amazingly enough, it *is* used in some pretty big production programs.
> Many CPU vendors use djgpp to build their cross-development
> environment. djgpp itself is built with djgpp. ARDI uses djgpp to
> build their MAC emulator. Cygnus uses djgpp for all it's dos
> products.
I'm not going to question your reply, but it's strange that such bugs
should only appear in my applications?
>> - Memory allocation is still buggy. Library calls of spawn
>> and stat often result in segment violation at malloc+200.
> These are hard to fix, and I've been looking for them.
Considering the bugs shown in the symified logs, I just wonder how
it has ever been possible to get gcc etc. running. The only difference
I see is the fact, that I use my own memory handler that calls malloc
most times asking for n*4096 bytes, while other applications usually
request various sizes.
>> - Free physical memory reported is wrong when chunks bigger
>> than 4096 bytes are requested by malloc or sbrk.
> I've looked for this bug before with no luck, but I'll look again.
If you had studied output of the program I sent in May it would have
been quite obvious that the modification of malloc.c did not yet fix
all of it.
>> - Debugging of real world applications using spawn is very
>> difficult because the topline of go32 is not updated when
>> the spawned program terminates.
> This is a new complaint for me, but trivial to fix (I think).
I would be very happy to see that improvement because symify produces
wrong results when called with the wrong exe. I think it would be useful
to output path of the currently running program in the dump file so that
symify would need less arguments.
>> - When spawning to another exe (e.g. as.exe), topline often
>> shows something like 2M of swapped out ram, 244K of used
>> ram and 16K of free ram in a system with 12M free xms ram
>> where swapping should not occur at all. It then spends most
>> of the time in real mode and execution is extremely slowed
>> down.
> When you spawn another program, everything is swapped out just in
> case. 1.12 adds an override for this, but it only works in VCPI mode.
I am not surprised of the red number, but of the situation that the
child program always reports 244K of used and 16K of free RAM (Who has
eaten the remaining 10M Bytes since the parent application which took
about 2M is swapped anyway??
>> - Calling system("mybat.bat arg1 arg2") hangs.
> I've never heard of this before. Have you reported it before?
Yes, in February.
>> Having reported the memory problems to DJ in May without any
>> useful help, I am on the point to abandon djgpp with a sad
>> feeling.
> Too bad. Perhaps you could help find and fix these bugs instead of
> just reporting them?
As you might have learned from all my previous mails I would of course
like to cooperate as much as possible.
Since I am stuck with the current project I, also spent more than 12 hours
trying to find the malloc bug. Due to very scarce comments in the sources
I found no solution:
First I tried to rebuild the libray with debugging defined in malloc.c,
but make always crashed before the library was built.
Then I tried to figure out what actions are taken by sbrk when called from
moreram. Somewhere close to cant_ask_for() I lost track of what your code
intended to do... :-((
My conclusion after all:
It's just plain luck (some call it Murphy's law) that some useful
applications can be built, but some subtle bugs still remain to
be caught.
Since the pointers returned by sbrk/malloc do no longer overlap, it is
difficult to imagine why segment violations always occur at malloc+200,
regardless what library function called it. Most often calls of stat and
spawn trigger it, but other library functions do it too.
In addition to that, sometimes a variable holding the handle of an open
file, which was < 10 when opened, is magically changed to 26 and this
triggers an error when calling any file operations with that modified
handle value.
From these observations I guess that somewhere (in the library?) a
dangling pointer might overwrite static data used by malloc.
This might be detected by using a watchpoint in gdb, but only after
having sucessfully rebuilt the library with debug information.
Kind regards
H. Ellenberger
-------------
- Raw text -