🚀 go-pugleaf

In article <1993Jan13.173450.1084@beckman.com>, rariedel@beckman.com (Bob Riedel) writes:
> In article <1993Jan13.115314.1082@beckman.com>, rariedel@beckman.com (Bob Riedel) writes:
>> Is there a problem with using the malloc() family in a PM app? I keep getting
>> segment violations in something called searchseg() inside malloc() when I
>> (or _beginthread) use this call.
>> 
>> Does this mean I have to use the Window heap manager calls instead of malloc()?
>> 
>> If so... that sucks!
> 
> I did not mention that I am trying to build an APP using GPF for OS/2 V1.3
> using the Microsoft C6.0 compiler.

I've also seen this behaviour. I traced the lockup into
DosReallocSeg, which is called when malloc needs to grow the heap
segment to allocate more memory.  My solution was to set the global
malloc variable _amblksiz (defined in malloc.h) to a value close to
64k. This variable specifies the size of the DosAllocSeg allocation
that malloc will initially make. When it uses up this amount, malloc
must call DosReallocSeg to grow the segment, or if it's at maximum
size, call DosAllocSeg to start a new one.  This forces malloc to
always make initial segment allocations the maximum size, thus never
calling DosReallocSeg.

You can see that that's why malloc works for awhile, then croaks. It
keeps allocating from the initial segment (I think it defaults to
8k), and when it runs out and calls DosReallocSeg, wham!

I sure wish I knew what was really going on, though. I think the MS
runtime is somehow corrupting the OS.