=99784= The main thread stack size used in this run was 8388608.MacOS 11.0 Big Sur, the successor to macOS 10.15 Catalina showcases some big changes. =99784= main thread stack using the -main-stacksize= flag. =99784= possible), you can try to increase the size of the =99784= overflow in your program's main thread (unlikely but =99784= If you believe this happened as a result of a stack =99784= Access not within mapped region at address 0x8 =99784= Process terminating with default action of signal 11 (SIGSEGV) =99784= Address 0x8 is not stack'd, malloc'd or (recently) free'd =99784= by 0x1000110C8: dyldbootstrap::start(dyld3::MachOLoaded const*, int, char const**, dyld3::MachOLoaded const*, unsigned long*) (in /usr/lib/dyld) =99784= Using Valgrind-3.17.0.GIT-lbmacos and LibVEX rerun with -h for copyright info =99784= Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. =99784= Memcheck, a memory error detector P.S.: Paul Floyd confirmed that the missing leak tracking is also due to that issue, so hopefully Valgrind should be back to normal once this is fixed. Overall, I am pretty confident supporting the cache is doable (if I can resolve the _DATA, big unknown!) and shouldn't take a massive amount of time (I don't want to promise this year, but I'll try my best). Valgrind has warnings against mmaping big chunks of memory but if I don't do that, I need to manually mark anything dyld is likely to read as accessible otherwise it throws ~3k errors, so either I disable the warnings when mmap-ing the dyld cache or I do it super granularly but I'll miss a lot of chunks and some warnings will slip through.I am still fuzzy on where/how _DATA is mapped when dyld uses the cache, thus unable to replicate it in Valgrind.Valgrind is heavily geared around loading Mach-O (or any format really) files from disk and thus I have to heavily alter the debuginfo component to allow me to load from memory.I am now running into the following issues: dyld uses stat64 to check if a library is on disk before checking into the cache, so I use this as a hint (if they fail and the path look like a lib) and then check the cache myself. Just wanted to share a quick progress update, I have now replicated dyld's cache loading logic and can retrieve dylibs from the cache. =48623= ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) =48623= For lists of detected and suppressed errors, rerun with: -s =48623= All heap blocks were freed - no leaks are possible =48623= total heap usage: 0 allocs, 0 frees, 0 bytes allocated =48623= in use at exit: 0 bytes in 0 blocks =48623= Warning: set address range perms: large range [0x7fffe1cea000, 0x7fffffe00000) (noaccess) =48623= Warning: set address range perms: large range [0x7fffc0002000, 0x7fffe1cea000) (defined) =48623= Using Valgrind-3.17.0.GIT-lbmacos and LibVEX rerun with -h for copyright info =48623= Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. =48623= Memcheck, a memory error detector
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |