tcmalloc segment

[XlousZ]

When I do secondary development on yadcc daemon, the newly developed module causes segment errors. I feel confused as to what causes the problem.

the following cases:

• 1 @ 0x7fe968d7dc70 (unknown) @ 0x55f7bc7b1ea3 tcmalloc::ThreadCache::ReleaseToCentralCache() @ 0x55f7bc7b21f5 tcmalloc::ThreadCache::ListTooLong()
• 2 @ 0x7fb467824c70 (unknown) @ 0x560a2ffc98d3 tcmalloc::CentralFreeList::FetchFromOneSpans() @ 0x560a2ffc9b9c tcmalloc::CentralFreeList::FetchFromOneSpansSafe() @ 0x560a2ffc9c63 tcmalloc::CentralFreeList::RemoveRange() @ 0x560a2ffd1d02 tcmalloc::ThreadCache::FetchFromCentralCache()

The newly developed module: Flare::Fiber used

[0x804d8000]

Just using fiber is unlikely to cause memory corruption.

Try enabling asan to see if something went wrong. Enabling asan can be done by editing BLADE_ROOT and adding -fsanitize=address to cppflags and ldflags.

Note that you may need to remove tcmalloc from deps before linking against asan.

[XlousZ]

Thanks for your suggestions. The memory problem was resolved by enabling asan.

But in the process, there was a problem. After enabling asan, the following error is reported during complication.

[5/427] FLARE //yadcc/api:flare_gen_scheduler_proto_flare
FAILED: build64_debug/yadcc/api/scheduler.flare.pb.h build64_debug/yadcc/api/scheduler.flare.pb.cc 
thirdparty/protobuf/bin/x86_64/protoc-3.4.1 --proto_path=. -I=thirdparty/protobuf-3.4.1/src -I=`dirname yadcc/api/scheduler.proto` --plugin=protoc-gen-flare_rpc=build64_debug/flare/rpc/protocol/protobuf/plugin/v2_plugin --flare_rpc_out=build64_debug yadcc/api/scheduler.proto && cd /usr1/YADCC && ls build64_debug/yadcc/api/scheduler.flare.pb.h build64_debug/yadcc/api/scheduler.flare.pb.cc > /dev/null
==29893==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
--flare_rpc_out: protoc-gen-flare_rpc: Plugin failed with status code 1.

As prompted, when i put LD_PRELOAD in front of the blade. then it reported many memory leek problems. When I next removed LD_PRELOAD, it compiled successfully.
Where should LD_PRELOAD be set?

LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libasan.so.5 ./blade build -p=debug yadcc/...

Indirect leak of 536 byte(s) in 1 object(s) allocated from:
    #0 0x7f578d013f90 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf90)
    #1 0x555edaa8d44d  (/usr/bin/python2.7+0x5744d)

[0x804d8000]

This is a known limitation with asan.

Someone (presumably admin of your system) set up one or more shared objects to be loaded on program startup, and that would conflict with asan. I’m not sure there’s much we can do about this.