diff: fix bug with memory profiling and interactive queries
Fergus Henderson
fjh at cs.mu.OZ.AU
Wed Mar 31 22:45:53 AEST 1999
On 31-Mar-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
>
> runtime/mercury_heap_profile.c:
> When inserting new nodes into the heap profiling table,
> allocate a new copy of the procedure name string, rather
> than just copying the pointer. This is needed in case
> the procedure name string is later deallocated. The
> procedure name string will normally be a string literal,
> but even then, if it was in a dynamically loaded module
> it may still be deallocated, using dlclose().
Sorry, the previous diff caused a compiler warning about `call to
strcpy() discards const'. This revised diff fixes the problem.
In future, I will try to remember to compile these things and
check for warnings _before_ sending off the mail...
Index: runtime/mercury_heap_profile.c
===================================================================
RCS file: /home/mercury1/repository/mercury/runtime/mercury_heap_profile.c,v
retrieving revision 1.1
diff -u -r1.1 mercury_heap_profile.c
--- mercury_heap_profile.c 1997/12/05 15:56:34 1.1
+++ mercury_heap_profile.c 1999/03/31 12:39:35
@@ -88,8 +88,20 @@
** create a new node for it.
*/
if (!found) {
+ char *copy_of_name;
+
node = MR_PROF_NEW(MR_memprof_record);
- node->name = name;
+ /*
+ ** We need to make a fresh copy of the name,
+ ** rather than just copying the pointer, because
+ ** our caller may deallocate its copy of the name.
+ ** Normally the name will be a string literal,
+ ** but even then it might be a string literal from
+ ** a dlopen()'ed module which will later get dlclose()'d.
+ */
+ copy_of_name = MR_PROF_NEW_ARRAY(char, strlen(name) + 1);
+ strcpy(copy_of_name, name);
+ node->name = copy_of_name;
node->addr = addr;
node->left = NULL;
node->right = NULL;
--
Fergus Henderson <fjh at cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3 | -- the last words of T. S. Garp.
More information about the developers
mailing list