Why not just disable copy-pasted talloc once and for all? Corresponding patches been floating in ML for quite some time.
07.05.2015 10:40, Mike McTernan (wavemobile) пишет: > Hi, > > On 30.04.2015 20:33, Jacob Erlbeck wrote: >> On 30.04.2015 20:01, Holger Freyther wrote: >>> Did ASAN help? >> No, since the data seems to be taken from then fc struct, so the memory area >> is >> valid. ASAN was enabled and didn't complain. > > It wouldn't have helped here, but since ASAN is discussed in the context of > memory errors, I'd like to check that it's been considered that ASAN's > ability to detect and report memory errors may be being impaired by the use > of talloc - particularly use after free bugs. > > I took a very quick look at the talloc code, and it looks like the Valgrind > memory poisoning macros are added, but not in a way that I can see as being > active (missing #include of the Valgrind API headers + DEVELOPER needs to be > defined). The 2.1.2 version of talloc looks to be perhaps more complete in > this respect. > > I'm not sure if ASAN can utilise the Valgrind macros though - perhaps > something like Mozilla's approach to cover poisoning is needed: > https://dxr.mozilla.org/mozilla-central/source/mfbt/MemoryChecking.h > > Also I noticed that there is a --disable-talloc option to configure. I hoped > this would fall back to libc malloc/free, but it actually disables use of the > packaged talloc.c, and links with -ltalloc instead i.e. talloc isn't actually > disabled: > > if ENABLE_TALLOC > libosmocore_la_SOURCES += talloc.c > else > libosmocore_la_LIBADD += -ltalloc > endif > > It may be better named --disable-builtin-talloc. > > Kind Regards, > > Mike > -- best regards, Max, http://fairwaves.co
