T.R | Title | User | Personal Name | Date | Lines |
---|
973.1 | | RAB::DESAI | Jatin Desai | Mon Jun 19 1989 11:21 | 9 |
|
> Is it ok to mix malloc and XtFree calls, or ought
> we use malloc/free or XtCalloc/XtFree consistently?
I believe you can not mix-n-match malloc/XtMalloc and free/XtFree.
You must use the right (matching) one.
Jatin
|
973.2 | While we're on the subject, | POOL::HALLYB | The Smart Money was on Goliath | Mon Jun 19 1989 16:26 | 8 |
| Can one use LIB$GET_VM on VMS systems as well as *alloc/*free ?
Presuming, of course, the "free" routine corresponds to the "get"
routine.
Can be important when combining existing code into DW applications.
John
|
973.3 | Sure can | EVETPU::REINIG | This too shall change | Mon Jun 19 1989 16:30 | 5 |
| Sure can. TPU uses LIB$GET_VM. Since it calls the toolkit, it also
uses *alloc/*free. FAKE_VM helps with all of this.
August G. Reinig
|
973.4 | difference? | BUFFER::RITTO | | Thu Jun 22 1989 11:12 | 6 |
| What's the difference between using malloc and XtMalloc? Is
there a reason to use one over the other?
Confused, but thankful,
Pat
|
973.5 | | CASEE::LACROIX | Gone with the wind | Thu Jun 22 1989 11:42 | 16 |
| > What's the difference between using malloc and XtMalloc? Is
> there a reason to use one over the other?
In general, XtMalloc/XtFree is supposed to be a lot faster than
malloc/free in the C RTL. But the most important things is that some of
the stuff you have XtMalloced maybe later XtFreed or XtRealloced by
some toolkit code, or by some code you have stolen somewhere. XtFreeing
something that was malloced is potentially a serious problem. The rules
would be something like: when you are doing DECwindows programming, UI
stuff, use XtMalloc/XtFree (or XMalloc/XFree...), and whenever you are
interfacing with something else, THINK A LOT. It is very easy to shoot
yourself in the foot. And yes, FAKE_VM is absolutely GREAT for memory
corruptions (and you will have some).
Denis.
|
973.6 | Cheap plug for FAKE_VM | DDIF::BRAMHALL | Mark Bramhall, CDA architecture | Tue Jun 27 1989 17:04 | 7 |
| A cheap plug for FAKE_VM...
FAKE_VM remembers the allocation method (LIB$GET_VM, malloc, XtMalloc,
etc.) and will tell you if you are freeing the allocated memory with a
different method. Freeing with a different method is one of the surest
ways to totally corrupt your memory!
|
973.7 | For us, I found trivial cause | GRANDE::DIGRAZIA | | Wed Jul 05 1989 12:30 | 17 |
|
Speaking of sure ways to corrupt memory, I entered the base
note because we had semi-reproducible explosions in our code,
which we decided were caused by something haywire in our
dynamic-memory stuff.
We knew we had a few malloc/XtFree combinations, etc.
But it turns out that I found some simple, old-fashioned
overruns in one of our modules. (I found a strcpy moving
too-long strings into malloc'd memory, thereby overwriting
malloc's bookkeeping words.)
Many thanks for assistance.
Regards, Robert.
|