Unable to profile memory

[PFOllagnon]

Hello,

I have already rise an issue some years ago on the mailing list. (for 4.3). At this time I ended up going back and use 3.1. Hence it seems that you have made some stuff for the memory profiling but I'm still not able to use it.

> more test_mem.scm 
(module test-main
        (main main)
        (eval (export-all)))
(define (main argv)
  (print "toto"))

Then for compilation I have tried -safe -unsafe, tried to add the pthread library, I always get a segfault. (compilation with bigloo -pmem test_mem.scm)

I have launched it thru gdb and I get this:

0x00007ffff4e35dc9 in bstring_to_keyword (name=0x7ffff5266f07) at Clib/cdsssl.c:70
70     BGL_MUTEX_LOCK( keyword_mutex );
Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7.x86_64 gmp-6.0.0-15.el7.x86_64
(gdb) bt
#0  0x00007ffff4e35dc9 in bstring_to_keyword (name=0x7ffff5266f07) at Clib/cdsssl.c:70
#1  0x00007ffff7ff1adb in bstring_to_keyword (n=0x7ffff5266f07) at lib/wrapper.c:249
#2  0x00007ffff7afa2ef in bgl_init_socket () at Clib/csocket.c:231
#3  0x00007ffff4e25ba9 in bgl_init_objects () at Clib/cinit_obj.c:76
#4  0x00007ffff7fef38a in bgl_init_objects () at lib/init.c:565
#5  0x00007ffff7ae604d in _bigloo_main (argc=1, argv=0x7fffffffca58, env=0x7fffffffca68, bigloo_main=0x400f57 <bigloo_main>, libinit=0x400e48 <bigloo_libinit>, uheapsize=<optimized out>) at Clib/cmain.c:194
#6  0x0000000000400ea5 in main (argc=1, argv=0x7fffffffca58, env=0x7fffffffca68) at test_mem.c:106

I arrive to this part of the code where obviously, there is already some debug stuff ^^

      protoent_mutex = bgl_make_spinlock( protoent_mutex_name );
#if defined( DEBUG_SEGV )
      socket_port_mutex = bgl_make_mutex( socket_port_mutex_name );
#endif

      so_keepalive = string_to_keyword( "SO_KEEPALIVE" );

what it the status of this topic ?

Can I help in something ?

Also there is an example in the /bmem directory wich doesn't seems to compile (it seems that it use a class definition but a struct method to access attributes)

Best regards, Pierre-Francois

[manuel-serrano]

Hi Pierre-Francois,

My apologize for the latency of this reply, but it gives me the opportunity to wish you an happy new year.

I have tried your example on my computer and I get:

-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- $ bigloo -pmem foo.scm
$ bglmemrun ./a.out Bmem initialization... Loading library /home/serrano/prgm/project/bigloo/bigloo/lib/bigloo/4.5b/libbigloogc-4.5b.so... Loading library /home/serrano/prgm/project/bigloo/bigloo/lib/bigloo/4.5b/libbigloo_s-4.5b.so... toto

=================================================== allocation size: 0.11MB

Clib/cvector.c: 94: 0.04MB 35.44% [ 48] (vector)

---

allocation count: 1821 vector : 0.05MB 48.13% [ 260] string : 0.03MB 24.96% [ 750] symbol : 0.02MB 14.40% [ 673] class : 0.01MB 6.24% [ 37] mutex : 0.00MB 1.43% [ 20] keyword : 0.00MB 1.31% [ 61] -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----

Which is the expected behavior. Thenb I have tried:

-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|----- $ cat > foo.scm << EOF (module test-main (library pthread) (main main) (eval (export-all)))

(define (main argv) (thread-join! (thread-start-joinable! (instantiate::pthread (body (lambda () (print "toto"))))))) EOF $ bigloo -pmem foo.scm $ a.out toto

bglmemrun ./a.out Bmem mt initialization... Loading library /home/serrano/prgm/project/bigloo/bigloo/lib/bigloo/4.5b/libbigloogc_mt-4.5b.so... Loading library /home/serrano/prgm/project/bigloo/bigloo/lib/bigloo/4.5b/libbigloo_s_mt-4.5b.so... toto

=================================================== allocation size: 0.59MB

Clib/cstring.c: 24: 0.09MB 15.58% [ 3471] (string) objs/obj_u/Eval/evenv.c: 593: 0.10MB 16.23% [ 2087] (vector) Clib/cvector.c: 94: 0.05MB 8.09% [ 102] (vector) Clib/csymbol.c: 64: 0.08MB 13.20% [ 3395] (symbol, ?) 105: 0.04MB 5.96% [ 2301] (pair) objs/obj_s/Ieee/symbol.c: 822: 0.03MB 5.54% [ 2137] (pair) 820: 0.03MB 5.54% [ 2137] (pair)

---

allocation count: 22361 pair : 0.18MB 30.29% [ 11689] vector : 0.18MB 29.99% [ 2702] string : 0.11MB 18.50% [ 3769] symbol : 0.08MB 13.18% [ 3390] procedure : 0.02MB 3.25% [ 373] -----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----|-----

Which is also the intended behavior. We can notice that in the first case bglmemrun used the single-threaded version of the bigloo lib and the multithreaded (_mt) in the second case. I suspect that for some reson, something goes wrong with your bglmemrun that is not able to detect which library to use. Could you show us precisely:

• how you compile your program;
• how to try to run it.

Thanks in advance.

[PFOllagnon]

No issue, Happy new year too !

I run it realy simply:

bigloo -pmem test_mem.scm bglmemrun a.out Bmem initialization... Loading library /bigloo/install/bigloo4.4c-rh76/lib/bigloo/4.5a/libbigloogc-4.5a.so... Loading library /bigloo/install/bigloo4.4c-rh76/lib/bigloo/4.5a/libbigloo_s-4.5a.so... /bigloo/install/bigloo4.4c-rh76/bin/bglmemrun: line 116: 30014 Segmentation fault LD_PRELOAD="$lib$libextra $libbacktrace" $exe $args

I have tried all combinations of _u _s and _mt with -t -u -s when running bglmemrun. None of theme are working and .so versions are correclty selected.

If working on your side, it means that something is happening specifically on my linux config ...

[manuel-serrano]

In the bigloo/bde/bmem/etc there is a script called bmemrun-gdb that I use to run profiled application under gdb. You may have a look at this one. Maybe it will help us understand what's wrong.

ps: could you send the configure.log. Maybe we will see interesting information there.

[PFOllagnon]

Hello manuel, Sorry, when things are not Urgent, they fall into the backlog :-(

I have tried the bmemrun-gdb that gave the exact same result than what I give in post #1

Here is the configure.log file. Does it help you ?

configure.log

[manuel-serrano]

Sorry for the awfully late follow up. I have just added an entry in the Bigloo manual for the memory profiler. I hope it will let you use the memory profiler more easily now.

Once again, my apologizes for the latency of this reply.