https://bugs.kde.org/show_bug.cgi?id=514297
--- Comment #25 from Mark Wielaard <[email protected]> --- (In reply to mcermak from comment #23) > > > I've used the following systemtap script to monitor the madvise syscall > > > system-wide: > > > > > > # stap -ve 'probe syscall.madvise {printdln(" ", advice_str, execname())}' > > > > Would be interesting to see the print_ustack (); for that to know what user > > space code decides to use guard pages. > > I've triggered the guard page installation like this: > > f44 x86_64 # python3 -c 'import time, threading; [threading.Thread(None, > lambda: time.sleep(1)).start() for x in range(1)]' > > Here is the stap output: > > # stap -d kernel -d /usr/lib64/libc.so.6 -d /usr/lib64/libpython3.14.so.1.0 > -ve 'probe syscall.madvise {printdln(" ", advice_str, execname()); > print_ustack(ubacktrace());}' > Pass 1: parsed user script and 486 library scripts using > 374948virt/132636res/17572shr/149148data kb, in 250usr/120sys/139real ms. > Pass 2: analyzed script: 3 probes, 12 functions, 98 embeds, 4 globals using > 501592virt/260972res/19248shr/275792data kb, in 2410usr/180sys/2612real ms. > Pass 3: translated to C into > "/tmp/stapKm0bBn/stap_a336501c0a7864a8b6be6371f4b58ca3_69324_src.c" using > 502012virt/266600res/24816shr/275928data kb, in 940usr/160sys/2507real ms. > Pass 4: compiled C into "stap_a336501c0a7864a8b6be6371f4b58ca3_69324.ko" in > 11420usr/1240sys/7124real ms. > Pass 5: starting run. > 0x66 python3 > 0x7f17a96f8c0b : __madvise+0xb/0x30 [/usr/lib64/libc.so.6] > 0x7f17a9679633 : pthread_create@@GLIBC_2.34+0xb23/0x1150 > [/usr/lib64/libc.so.6] > 0x7f17a9b1d10c : do_start_joinable_thread.constprop.0+0xbc/0x120 > [/usr/lib64/libpython3.14.so.1.0] > 0x7f17a9b1ce52 : PyThread_start_joinable_thread+0x32/0x60 > [/usr/lib64/libpython3.14.so.1.0] > 0x7f17a9b1cbfb : do_start_new_thread.lto_priv.0+0x19b/0x230 > [/usr/lib64/libpython3.14.so.1.0] > [ ... stuff deleted ... ] > 0x7f17a9a8cac0 : Py_RunMain+0x540/0x660 [/usr/lib64/libpython3.14.so.1.0] > 0x7f17a9a868ac : Py_BytesMain+0x3c/0x60 [/usr/lib64/libpython3.14.so.1.0] > 0x7f17a9608681 : __libc_start_call_main+0x81/0x110 [/usr/lib64/libc.so.6] > 0x7f17a9608798 : __libc_start_main@GLIBC_2.2.5+0x88/0x150 > [/usr/lib64/libc.so.6] > 0x5588748003d5 : 0x5588748003d5 [/usr/bin/python3.14+0x3d5/0x4000] > WARNING: Missing unwind data for a module, rerun with 'stap -d > /usr/bin/python3.14' > MADV_DONTNEED Thread-1 (<lamb > 0x7f17a96f8c0b : __madvise+0xb/0x30 [/usr/lib64/libc.so.6] > 0x7f17a9678aac : start_thread+0x54c/0x5b0 [/usr/lib64/libc.so.6] > 0x7f17a96fcc0c : __GI___clone3+0x2c/0x60 [/usr/lib64/libc.so.6] > # OK, so that is when setting up new threads, the stack gets a guard page? Which explains your choice for using VG_N_THREADS for the max number of guard pages to track. Expecting 1 per thread. > > You still would like to use /proc/self/pagemaps for sanity checks though > > (--sanity-level=3 testing) > > Done: > https://sourceware.org/git/?p=valgrind.git;a=blob;f=coregrind/m_aspacemgr/ > aspacemgr-linux.c;h=7b449fd7a2a9204ffd6da7b9ca81e1847e08ef24; > hb=8727ba9b9edc9ebb053bb63e8eb8c8c49287f77a#l1162 OK, nice, so when is_guarded is called, we do a sanity check that our internal data (still) matches the /proc/self/pagemap guard bit. I think that can/should be extended to also trigger for when AM_SANITY_CHECK/am_do_sync_check is called. Probably added to parse_procselfmaps and/or the sync_check_mapping_callback. So each segment is checked for matching /proc/self/maps and then for each segment to check whether or not it contains guard pages according to /proc/self/pagemap. But this might be a lot of extra work. Would still be useful to catch issues though. -- You are receiving this mail because: You are watching all bug changes.
