I think I found it, I was wrong above where I said that at first I did not have address sanitizer enabled. Seems when I disable it, I no longer see any "Segmentation fault" messages nor memory leak reports from the sanitizer (obviously).
That is a problem. When you say that gdb doesn't show anything > useful, what do you mean? Does it at least show where the > segmentation fault is occurring? When I run it through gdb with memory sanitizer enabled I only see the memory leak reports. Never the "Segmentation fault" message. When I don't run it through gdb, I sometimes see the memory leak report, but sometimes the "Segmentation fault" message which looks like this: # ./a.out Options: --help Produce this help message --repo arg (=./repo) Path to the repository Segmentation fault # Where the "Options:..." part is my output but the "Segmentation fault" line is not mine. enable it, say, by executing > ulimit -c unlimited > before starting the problem. Thanks for the hint, but I already had it enabled. What C library are you using? # ldd a.out linux-vdso.so.1 => (0x00007fffdd70e000) libasan.so.2 => /usr/lib/x86_64-linux-gnu/libasan.so.2 (0x00007f636ebfa000) libevent-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 ( 0x00007f636e9b4000) libevent_pthreads-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent_pthreads- 2.0.so.5 (0x00007f636e7b0000) libboost_program_options.so.1.58.0 => /usr/lib/x86_64-linux-gnu/ libboost_program_options.so.1.58.0 (0x00007f636e532000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 ( 0x00007f636e1b0000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f636df99000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 ( 0x00007f636dd7c000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f636d9b2000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f636d7ad000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f636d4a4000) libevent_core-2.0.so.5 => /usr/lib/x86_64-linux-gnu/libevent_core-2.0.so.5 (0x00007f636d27a000) /lib64/ld-linux-x86-64.so.2 (0x000056445740e000) > But if I'm right that this is related to exiting while the > runtime is being initialized, then a workaround would be to call any > Go function on exit, even a Go function that does nothing. This is interesting, when I call a "go_do_nothing()" function right before `return 0;` from the C++ main function , run the executable NOT through gdb, and with memory sanitizer enabled, I only see the "Segmentation fault" messages. Very consistently and never any memory leak reports. When I run it through gdb however I do sometimes see the mem leaks, never any crash though. I think it looks like the sanitizer fault now. I'll try to upgrade and come back. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
