This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
☎ Max.Suraev at fairwaves.coWhy 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