On 23.09.2019 00:21, Brett Lymn wrote: > > Folks, > > I have been sloppy with my memory allocations and use in hte libcurses > testframe which, though the code seems to work, some tests fail when > jemalloc is enabled. I am trying to work out where to look but it is > difficult becuse there are lots of little memory allocations all over > the place. It was suggested to me to set MKSANITIZER=yes to try and > catch the errors. Sure enough, if I build the curses test frame with > MKSANITIZER=yes then the test process gets terminated and I get a memory > map dumped like this: > > [blymn@rover] ./debug_test -v mvscanw > ==15885==Shadow memory range interleaves with an existing memory > mapping. ASan cannot proceed correctly. ABORTING. > ==15885==ASan shadow was supposed to be located in the > [0x00007fff7000-0x10007fff7fff] range. > ==15885==Process memory map follows: > 0x0001f0e00000-0x0001f0e25000 > /usr/tests/lib/libcurses/director > 0x0001f1025000-0x0001f1026000 > /usr/tests/lib/libcurses/director > 0x0001f1026000-0x0001f102c000 > /usr/tests/lib/libcurses/director > 0x0001f102c000-0x0001f102e000 > 0x7c6c0aaae000-0x7c6c0ae00000 > 0x7c6c0ae00000-0x7c6c0ae13000 /lib/libgcc_s.so.1.0 > 0x7c6c0ae13000-0x7c6c0b012000 /lib/libgcc_s.so.1.0 > 0x7c6c0b012000-0x7c6c0b013000 /lib/libgcc_s.so.1.0 > 0x7c6c0b013000-0x7c6c0b014000 /lib/libgcc_s.so.1.0 > 0x7c6c0b200000-0x7c6c0b202000 /usr/lib/librt.so.1.1 > 0x7c6c0b202000-0x7c6c0b401000 /usr/lib/librt.so.1.1 > 0x7c6c0b401000-0x7c6c0b402000 /usr/lib/librt.so.1.1 > 0x7c6c0b402000-0x7c6c0b403000 /usr/lib/librt.so.1.1 > 0x7c6c0b600000-0x7c6c0b610000 /usr/lib/libpthread.so.1.3 > 0x7c6c0b610000-0x7c6c0b80f000 /usr/lib/libpthread.so.1.3 > 0x7c6c0b80f000-0x7c6c0b810000 /usr/lib/libpthread.so.1.3 > 0x7c6c0b810000-0x7c6c0b811000 /usr/lib/libpthread.so.1.3 > 0x7c6c0b811000-0x7c6c0b812000 > .... and so on... > > So, yes, I have a problem but I don't know where. How can I get more > information to help me find out where the issue is? > > I am running a -current from around the end of April. I can update if I > really need to (I lag behind because this laptop is the machine I use > most so I like it stable...) > This issue is caused by ASLR. Please disable it globally (security.pax.aslr.enabled) or per-application. Newer (including the MKLLVM ones) sanitizers will bail out with a verbose message here. Ideally please upgrade to -current and use LLVM, but maybe it is not needed in this case.
Attachment:
signature.asc
Description: OpenPGP digital signature