[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference bulova::decw_jan-89_to_nov-90

Title:DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:STAR::VATNE
Created:Mon Oct 30 1989
Last Modified:Mon Dec 31 1990
Last Successful Update:Fri Jun 06 1997
Number of topics:3726
Total number of notes:19516

3567.0. "DWT$STRING_FREE_CONTEXT not freeing memory $GET_NEXT_SEGMENT." by SFCPMO::MILLER (Miles to go before I sleep...) Thu Nov 01 1990 14:03

Hello!

I am having memory allocation problems using DWT$STRING_INIT_CONTEXT,
DWT$GET_NEXT_SEGMENT, and DWT$STRING_FREE_CONTEXT.  The general flow
of code is as follows:


      STATUS = DWT$STRING_INIT_CONTEXT( LB_CONTEXT,
     1                                  %VAL(CS_PTR))

      STATUS = DWT$GET_NEXT_SEGMENT( LB_CONTEXT,
     1                           STR_VALUE,
     2                           STR_LEN,
     3                           CHARSET,
     4                           R_TO_L,
     5                           LANG,
     6                           REND)

      CALL DWT$STRING_FREE_CONTEXT(LB_CONTEXT)


This section of code gets a string from a listbox item.  Repetetive
calls causes the program to run out of virtual memory.  After running
the code in debug, I found that DWT$GET_NEXT_SEGMENT is the culprit
for dynamic allocation of memory.  I was expecting
DWT$STRING_FREE_CONTEXT to free the memory allocated by
DWT$GET_NEXT_SEGMENT but it didn't.  The way I noticed this was using
another process and monitoring the program's Private and Global Page
Count with F$GETJPI.  PPGCNT increased a few pages every 3 or 4 calls
to DWT$GET_NEXT_SEGMENT but never went down after the calls to
DWT$STRING_FREE_CONTEXT. 

I'd be gratefull for any help in solving this problem or a possible
work-around.  We intend to do this sort thing several thousand times
during an application's run-time session. 

Thanks

Matt Miller  ;-)
T.RTitleUserPersonal
Name		DateLines
3567.1Where's the CS going?TOOLEY::B_WACKERThu Nov 01 1990 17:123
You probably need to XT$FREE %VAL(CS_PTR) on each iteration.

Bruce
3567.2Won't that mess up the listbox?SFCPMO::MILLERMiles to go before I sleep...Fri Nov 02 1990 00:1721
But wouldn't that cause my compound string in the listbox to be
deallocated?  And then cause a crash when the widget tried to display
the compound string (e.g., on an expose event)?  You know something
about finding the memory for the string no longer valid? 

I wonder if what's really happening here is that DWT$GET_NEXT_SEGMENT
is grabbing the compound string data structure and dynamically
creating a new copy of it somewhere else in memory.  Then it can do
destructive things to it without harming the widget's data structure.

Something else that's kinda interesting: the CS context is made up of
two longwords where the first is an address and the second is an
offset.  Why is it that the address is always 0 and the offset look
suspiciously like an address? 

Anyway, thanks for the idea.  I'll see what happens when I try
XT$FREE(%VAL(CS_PTR)).  I think I'll also try using
XT$FREE(%VAL(LB_INDEX(2))).


Matt
3567.3Some infoLEOVAX::TREGGIARIFri Nov 02 1990 08:2126
> But wouldn't that cause my compound string in the listbox to be
> deallocated?  
    
    No
    
> I wonder if what's really happening here is that DWT$GET_NEXT_SEGMENT
> is grabbing the compound string data structure and dynamically
> creating a new copy of it somewhere else in memory. 
    
    Yes
    
> Something else that's kinda interesting: the CS context is made up of
> two longwords where the first is an address and the second is an
> offset.  Why is it that the address is always 0 and the offset look
> suspiciously like an address? 
    
    Don't touch anything inside the context.  I don't remember exactly
    what's in the two lonwords, but in DECwindows V1, the two lonwords
    were sufficient to hold the entire context.  In DECwindows V2, we
    needed more information, but we had made the mistake in V1 of 
    having the application allocate the context, so we couldn't change
    the size.  So, one of those two lonwords points to another
    data structure.
    
    Leo
3567.4Which variable do I use for XT$FREE?SFCPMO::MILLERMiles to go before I sleep...Fri Nov 02 1990 09:2210
If DWT$GET_NEXT_SEGMENT is dynamically allocating memory, how do I
free this memory?  I *assumed* that DWT$STRING_FREE_CONTEXT would do
this for me.  If this isn't the case, then which variable has the
compound string pointer?  Do I use the one which I pulled from the
listbox items list?

I appreciate everyone's ideas.

Matt
3567.5QUARK::LIONELFree advice is worth every centFri Nov 02 1990 10:2814
Do NOT free the compound string if you got it by calling XT$GET_VALUES, or
pulled it off a callback data structure.

Looking at the manual, it seems you may be out of luck.  The C routine
allocates space for the ASCIZ string, and the manual says you should free
it.  The VAX routine probably calls the C routine, copies the string into
your descriptor, and then doesn't free the string from the C routine.

I'd suggest trying to use the C routine for GET_NEXT_SEGMENT instead, finding
the length with INDEX or LIB$LOCC, and copying the string to your own
CHARACTER variable, then free the ASCIZ string.  (I'm a bit puzzled about
the manual saying to use XT$FREE - isn't that only for compound strings?)

				Steve
3567.6Confirming Steve's guessTOOLEY::B_WACKERFri Nov 02 1990 13:074
Bingo!  The 5.3 source for DWT$GET_NEXT_SEGMENT doesn't free the text 
after copying to your descriptor.  Someone should QAR it.

Bruce
3567.7XtFree not just for compound stringsLEOVAX::TREGGIARISat Nov 03 1990 09:399
> (I'm a bit puzzled about
> the manual saying to use XT$FREE - isn't that only for compound strings?)

    No.  XtFree/XT$FREE must be used with anything allocated with
    XtMalloc, XtCalloc, XtRealloc.  The toolkit uses those for all
    memory that it allocates, not just compound strings.
    
    Leo