Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Make the fb names static, to match dm names
Oof. Writing down the details on this one, as I doubt I'll remember... The start was turning on both the AddressSanitizer and Qt. When doing so, most programs suddenly began reporting memory leaks. However, the report was rather cryptic, being four entries similar to this one: ==1262202==ERROR: LeakSanitizer: detected memory leaks Direct leak of 21 byte(s) in 1 object(s) allocated from: #0 0x498087 in posix_memalign (build/src/libdm/tests/dm_test+0x498087) #1 0x7f4e90e53675 in alloc brlcad/src/libbu/malloc.c:129:10 #2 0x7f4e90e53400 in bu_malloc brlcad/src/libbu/malloc.c:167:12 #3 0x7f4e90ee1c02 in bu_strdupm brlcad/src/libbu/str.c:165:17 #4 0x7f4e87dcd3e9 (<unknown module>) #5 0x7f4e87dcdea5 (<unknown module>) #6 0x7f4e9650eb89 (/lib64/ld-linux-x86-64.so.2+0x11b89) I wasn't immediately sure if the unknown module error was related to the plugin loading, and spent a lot of time trying to find a string memory issue in dm_init.cpp. After that proved fruitless, other than to confirm that the error disappeared if i removed the bu_dlclose-ing of the handles saved at initialization, I began to look for ways to decode the "unknown module" entries. That led to the following issue: google/sanitizers#89 which describes the problem ASan has with dynamic libraries. Comments indicated that it would see real issues, but won't report which dynamic library they come from (and there are no plans to fix this anytime soon... grr...). In fairness, valgrind can see the error too but also has the same reporting problem; it appears to be ubiquitous. Fortunately, we have an alternative due to the way our plugin system and test apps work - we can simply add and remove .so files to the directory and see how the error reporting changes to zero in on which file(s) are triggering the problem. Doing so quickly made apparent what should have been obvious in retrospect - two of the errors each were coming from the Qt and swrast plugins, which had been off in earlier testing. Since there was no backtrace beyond the bu_strdupm call itself, and there were two errors per file, the suspect was the bu_strdup calls initializing the "char *" names for the fb structures. The C files use static strings (which is why the non-Qt plugins didn't show the issue), but C++ doesn't tolerate the type mismatch. The original hack workaround was just to bu_strdup and create a (char *) string, but as the leak detectors correctly note this also means there's no way to clean up the allocated memory. As far as I can tell there is no reason for these strings to be editable (char *) strings - the dm container's equivalents are static. This commit removes any logic assuming if_name is dynamic, and also removes the bu_strdup hack from Qt and swrast.
- Loading branch information