interactive queries, dlclose(), and profiling

[Fergus Henderson]

Hi,

The nightly tests on murlibobo (alpha-dec-osf3.2) failed the interactive query
test in grade asm_fast.gc.memprof.  The symptom is a segmentation violation.
I tracked the problem down, and it turns out to be due to the memory profiling
table containing references to string literals defined in the previous
libquery.so which has, by the time you run the second query, already been
dlclose()'d.

Any suggestions on what to do about this?

Some possible alternatives:

	- document that interactive queries are not supported in memory
	  profiling grades, and disable that test case

	- change the implementation of interactive queries so it never
	  calls dlclose(). 
	  
	  (A quick test suggests that simply commenting out the call to
	  dlclose is not enough, apparently -- if you dlopen()
	  libquery.so twice without calling dlclose(), then dlsym()
	  returns NULL.  I don't know exactly why.  Probably this could
	  be worked around by generating different modules query1,
	  query2, query3, ...  so that no symbol was defined twice,
	  rather generating the same module `query' each time.)

But neither of those seem like a great idea, because the same problem could
arise if you try to profile any Mercury program that calls dlclose.
Supporting dlopen & dlclose is nice, and supporting profiling is nice,
and so it rather unfortunate if they were mutually exclusive.

Another alternative would be to change the implementation of memory profiling
so that it makes a fresh copy of the procedure name string, rather than
just copying the pointer -- see the diff below.  That would solve the
current problem, albeit at some efficiency cost.  However, I suspect that
there are probably similar problems with other global tables used by
time profiling, call profiling, and the debugger itself.  And for time
profiling, the efficiency cost of the extra copying might be significant,
because it would cause the profiles to be a bit more skewed.

Suggestions?  Comments?

Index: mercury_heap_profile.c
===================================================================
RCS file: /home/mercury1/repository/mercury/runtime/mercury_heap_profile.c,v
retrieving revision 1.1
diff -u -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 10:19:34
@@ -89,7 +89,16 @@
 	*/
 	if (!found) {
 		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.
+		*/
+		node->name = MR_PROF_NEW_ARRAY(char, strlen(name) + 1);
+		strcpy(node->name, 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.