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/.
Mike McTernan (wavemobile) mike.mcternan at wavemobile.comHi, 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