Re: Free Info

Yes it did. free was being called instead of efree (line 1705 unified_odbc.c in version 3.0.5, line 1871 in the latest version). The problem I was tracking - short memory allocation for hashed_default (line 1766) did NOT exist - this appeared when the new layout for the unified_odbc code was implemented. Steve PS I also forgot to add the correction to CVS - I have just done it now... Zeev Suraski wrote: > > Does this problem exist in the 3.0.5 ODBC driver? Can you try to check out? > > Zeev > > At 15:02 11/12/98 +0000, Steve Williams wrote: > >Rasmus Lerdorf wrote: > >> > >> > Freeing 80c6cf8 (8 bytes), allocated in ðj > >> > > >> > on line 1799<br> > >> > Freeing 80c0558 (8 bytes), allocated in functions/unified_odbc.c on line > >> > 1799<br> > >> > > >> > > >> > The first Freeing statement looks as if the memory is screwed up - is > >> > this a valid assumption? > >> > >> Looks like it. But it would be safe to assume that it should have said > >> functions/unified_odbc.c. What is happening on line 1799 there? > >> > >> Basically what you are dealing with here is PHP's memory manager. The > >> emalloc() and related functions are used to request a block of memory from > >> PHP's memory manager. It does not necessarily have to be freed since the > >> memory manager will free it when the request terminates to ensure that > >> there will be no memory leaks. However, things allocated with emalloc(), > >> estrdrup(), etc. should be freed by calling efree(). If something is not > >> efreed()'ed you get the above warning. It is saying that an 8 byte chunk > >> of memory was allocated on line 1799 and was never freed'ed before request > >> shutdown and that the memory manager is freeing it. > >> > >> So, what you need to look at is what you are allocating here and where > >> this bit of memory should logically be freed'ed. It may not be the actual > >> cause of your problems, but it might point you in the right direction and > >> it should definitely be fixed. > >> > >> -Rasmus > >> > > > >1799 is allocation of a connection handle. Persistent handles are > >allocated using malloc, > >none-persistent handles are allocated using emalloc. I have discovered > >one place where the deallocation for a none-persistent handle uses free > >instead of efree (line 1868). Changing this gets rid of the debug > >message, but this doesn't solve the problem :-( > > > > > > Steve > > > > > > > >-- > >Steve Williams Interactive Media & Tools Group > >Empress Software Inc. http://www.empress.com > > > >-- > >PHP Development Mailing List http://www.php.net/ > >To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net > >For help: php-dev-help@lists.php.net > > > > > > > -- > Zeev Suraski <zeev@zend.com> > For a PGP public key, finger bourbon@netvision.net.il > > -- > PHP Development Mailing List http://www.php.net/ > To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net > For help: php-dev-help@lists.php.net -- Steve Williams Interactive Media & Tools Group Empress Software Inc. http://www.empress.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net