Hello, Sven,
The changes you made to bglmemrun script are helpful, but the underlying
problem is that the compilers is being compiled be default with
sharedlibraryclosed=yes resulting in both bmem.so and bmem_fth.so being linked
against the unsafe bigloo runtime when they are built. See the makefile snippet
below for bmem.so in bde/bmem/Makefile.
$(BOOTLIBDIR)/bmem/bmem.$(SHAREDSUFFIX): $(LIBOBJECT) $(BOOTLIBDIR)/bmem
$(MAKE) shared-lib \
OBJECTS="$(LIBOBJECT)" \
FORCELD=true \
LIBDEST=$(BOOTLIBDIR)/bmem/bmem.$(SHAREDSUFFIX) \
LIBPATH=$(BOOTLIBDIR) \
SONAME=bmem.$(SHAREDSUFFIX) \
CLOSELIBS="-lbigloo_u-$(RELEASE)"
This results in a segfault on my machine when attempting to memory profile a
safe program because both the safe and unsafe runtimes are loaded into memory.
On linux, we can solve this by not setting sharedlibraryclosed=yes but that
will only work on linux and similar systems that do not have to have all
symbols defined when building the library. It will not work for Windows or OSX.
Now, it is possible that on Windows and OSX things somehow work with both
libraries loaded but even then, it seems we are asking for problems.
Best Regards,Joseph Donaldson
From: Sven Hartrumpf <[email protected]>
To: [email protected]
Sent: Sunday, December 11, 2016 12:59 AM
Subject: Re: [bigloo] 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
