> I tried Mike's suggestion and add memset() after each malloc() and it still
 > crashes.
 PC>

 JdBP> In which case it cannot *possibly* be a problem with uncommitted
 JdBP> memory. 
 JdBP> Therefore it never *was* a problem with uncommitted memory.

I believe that's correct... could still be related to memory... I gues
everything is related to memory though... :-)

 JdBP> Incidentally, if "P" is freeing the memory that you
allocate using
 JdBP> malloc(), then (if it was halfway reasonably designed) it will be
 JdBP> assuming that the memory was allocated using DosAllocMem and will be
 JdBP> freeing it with DosFreeMem.

 JdBP> Therefore the best design is to leave the task of freeing memory up
 JdBP> to the entity that allocated it, and the second best design is to
 JdBP> always require that memory objects for which ownership is transferred
 JdBP> between DLLs to be allocated using the system-level API and not the
 JdBP> C++ runtime heap.

 JdBP> You'll have to check which one "P" uses.

I've corresponded with the author of P, and he only uses DosAllocMem in the
P.DLL, but there are about 3 calls to malloc()/free() in the brw.c (buffered
read/write routines).

I've done some debugging with TurboDebugger, and found that P is crashing in
the following code...


/* Makes an array of va_list */

void make_arg_list(U32 *arg_list, va_list arg_ptr, U32 cnt) {

  U32 idx;

  for (idx = 0; idx < cnt; idx++)
    arg_list[idx] = va_arg(arg_ptr, int);   // TurboDebugger crashes here
                                            // at byte  32773
                                            // idx = 9
                                            // cnt = 10
}

He thinks it is a memory problem (not necessarily malloc()), I am still
debugging...


         ////
        (o o)
----oOO--(_)--OOo----   phil.crown{at}bluecafe.com | Fido 1:124/6108.2

--- Blue Wave/OS2 v2.20y Beta