Re: debugging with dmalloc

Since we can't see the output, how can we tell? :-) I'd suggest using valgrind to track leaks, as it doesn't require you to link against any alternate allocators (it is best to build the libraries with debugging symbols though). Google will point the way. --Wez. On Mon, 2 Aug 2004 11:02:27 +0100 (BST), Swithun Crowe <swithun@swithun.com> wrote: > Hello > I've been tracking down memory leaks in a C++ extension I'm writing for > PHP5 (following J Smith's excellent tutorial). I compiled PHP with > --enable-dmalloc and --enable-debug and have managed to eradicate all > leaks that would get reported after running a script which uses my > extension. But using the dmalloc tool and getting leaks written to a log > file, I've found a whole lot more (which aren't dumped to stderr after > running, say, php -f myscript.php). > Can I assume that these leaks are not coming from PHP, but rather from the > libraries which I'm creating the PHP wrapper for (Sleepycat's DbXml)? > These libraries can't (I don't think) be compiled with dmalloc, so dmalloc > won't be able to tell me the offending line number and file, but just that > some memory was allocated and not freed. > > If this is the case, I'll be able to get on to the Sleepycat people and > see if they have any suggestions. But I thought I should try here first. > > If anyone can confirm or refute this hypothesis, or has any ideas which > might help, I would be grateful. > > Thanks. > > Swithun. > > -- > PECL development discussion Mailing List (http://pecl.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >