Re: Memory profiling with 4.3a

Hello Joseph.

You wrote, 2016-12-11 00:18:
 > Ok, after digging a bit more, it looks as though the issue is due to bmem
> being linked to libbigloo_u and the profiled program being linked to
> libbigloo_s. This results in two version of the runtime being loaded at
> once, and unfortunately, on linux at least, one set of functions are not
> used exclusively. I see bgl_get_symtab being used from one and
> bgl_init_symtable from the other, resulting in an unitialized symbol table
> being returned and a subsequent segmentation fault. After compiling the
> test program as unsafe, I was able to successfully use bmem.
> 
> To fix this, we will probably need to have both unsafe and safe versions of
> bmem and choose the appropriate version when running bmemrun.

If you apply the following patch before building bigloo:

--- bde/bmem/etc/bmemrun.in.orig	2016-12-07 14:20:46.000000000 +0100
+++ bde/bmem/etc/bmemrun.in	2016-12-11 09:55:26.964062670 +0100
@@ -28,10 +28,14 @@ while : ; do
     -h|--help)
       echo "bglmemrun: [options] exe [arg1] [arg2]..." >&2;
       echo "  -h|--help            -- This message" >&2;
+      echo "  -s|-safe|--safe      -- Preload safe libraries" >&2;
       echo "  -u|-unsafe|--unsafe  -- Preload unsafe libraries" >&2;
       echo "  -t|--thread          -- Profile multithreaded program" >&2;
       exit 0;;
 
+    -s|-safe|--safe)
+      export BMEMUNSAFE=_s;;
+
     -u|-unsafe|--unsafe)
       export BMEMUNSAFE=_u;;
 
the following will show the options you need (I am not sure whether
you need more):

> bglmemrun -h
bglmemrun: [options] exe [arg1] [arg2]...
  -h|--help            -- This message
  -s|-safe|--safe      -- Preload safe libraries
  -u|-unsafe|--unsafe  -- Preload unsafe libraries
  -t|--thread          -- Profile multithreaded program

Greetings
Sven

> Or we could
> also try not linking bmem with the runtime at all and rely on the dynamic
> loader to patch the symbols with those provided by the program to be
> profiled. Although, this will only work on systems that support unclosed
> libraries. For Windows and OSX, we will need safe threaded, safe
> unthreaded, unsafe threaded, and unsafe unthreaded variations of the
> libraries.
> What do people think? Are there other solutions I have not thought of?
> Thanks,Joseph Donaldson