Re: W^X issues running valgrind
On 2016-10-07, Andreas Kusalananda Kähäri wrote: > > Adding wxallowed to the mount options of every single partition and > adding -Wl,-z,wxneeded to every step of the compilation doesn't help > either. Scattering wxallowed flags on every partition is not going to do anything useful. Are your -Wl,-z,wxneeded changes working correctly? You need to be producing binaries with an OPENBSD_WXNEEDED section (visible with objdump -p). > It feels as if I'm missing something basic here. The basic thing is that somebody who is interested in running valgrind on OpenBSD needs to figure out how (and if it's possible) to use it now that we are doing W^X enforcement.
Re: W^X issues running valgrind
On Thu, Oct 06, 2016 at 03:42:54PM +0200, Andreas Kusalananda Kähäri wrote: > On Thu, Oct 06, 2016 at 12:57:43PM +0100, Stuart Henderson wrote: > > On 2016/10/06 13:23, David Coppa wrote: > > > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri > > > wrote: > > > > Hi, > > > > > > > > Let me know if this should be on ports rather than here. > > > > > > > > I'm following OpenBSD current on amd64, updating the system a couple of > > > > times a week, and I'm using valgrind from ports to check a C program for > > > > memory leaks. However, since recently (sorry, can't specify closer, > > > > within the last couple of months) I get a W^X violation when I try it. > > > > > > devel/valgrind is missing the USE_WXNEEDED=Yes marker. > > > > valgrind works by preloading an .so file and wrapping library functions > > to override with its own versions. > > > > You will at least need to link the program under test with -Wl,-z,wxneeded > > but you might need to do more than this. > > > > Adding USE_WXNEEDED=Yes to the valgrind port cuts down the error from > valgrind to just > > valgrind: mmap(0x108000, 4550656) failed in UME with error 12 (Cannot > allocate memory). > > ... and a notification of a W^X violation from the kernel as before. > Adding "-Wl,-z,wxneeded" when linking my application makes no > difference. I'm still trying to run it under /home with wxneeded added > to the mount flags as before. > > Is there anything else I could try? Adding wxallowed to the mount options of every single partition and adding -Wl,-z,wxneeded to every step of the compilation doesn't help either. It feels as if I'm missing something basic here. Andreas -- Andreas Kusalananda Kähäri Bioinformatics Developer NBIS, Uppsala University http://www.nbis.se/ [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: W^X issues running valgrind
On Thu, Oct 06, 2016 at 12:57:43PM +0100, Stuart Henderson wrote: > On 2016/10/06 13:23, David Coppa wrote: > > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri > > wrote: > > > Hi, > > > > > > Let me know if this should be on ports rather than here. > > > > > > I'm following OpenBSD current on amd64, updating the system a couple of > > > times a week, and I'm using valgrind from ports to check a C program for > > > memory leaks. However, since recently (sorry, can't specify closer, > > > within the last couple of months) I get a W^X violation when I try it. > > > > devel/valgrind is missing the USE_WXNEEDED=Yes marker. > > valgrind works by preloading an .so file and wrapping library functions > to override with its own versions. > > You will at least need to link the program under test with -Wl,-z,wxneeded > but you might need to do more than this. > Adding USE_WXNEEDED=Yes to the valgrind port cuts down the error from valgrind to just valgrind: mmap(0x108000, 4550656) failed in UME with error 12 (Cannot allocate memory). ... and a notification of a W^X violation from the kernel as before. Adding "-Wl,-z,wxneeded" when linking my application makes no difference. I'm still trying to run it under /home with wxneeded added to the mount flags as before. Is there anything else I could try? -- Andreas Kusalananda Kähäri Bioinformatics Developer NBIS, Uppsala University http://www.nbis.se/ [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: W^X issues running valgrind
On 2016/10/06 13:23, David Coppa wrote: > On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri > wrote: > > Hi, > > > > Let me know if this should be on ports rather than here. > > > > I'm following OpenBSD current on amd64, updating the system a couple of > > times a week, and I'm using valgrind from ports to check a C program for > > memory leaks. However, since recently (sorry, can't specify closer, > > within the last couple of months) I get a W^X violation when I try it. > > devel/valgrind is missing the USE_WXNEEDED=Yes marker. valgrind works by preloading an .so file and wrapping library functions to override with its own versions. You will at least need to link the program under test with -Wl,-z,wxneeded but you might need to do more than this.
Re: W^X issues running valgrind
On Thu, Oct 6, 2016 at 12:50 PM, Andreas Kusalananda Kähäri wrote: > Hi, > > Let me know if this should be on ports rather than here. > > I'm following OpenBSD current on amd64, updating the system a couple of > times a week, and I'm using valgrind from ports to check a C program for > memory leaks. However, since recently (sorry, can't specify closer, > within the last couple of months) I get a W^X violation when I try it. devel/valgrind is missing the USE_WXNEEDED=Yes marker. Ciao! David
W^X issues running valgrind
Hi, Let me know if this should be on ports rather than here. I'm following OpenBSD current on amd64, updating the system a couple of times a week, and I'm using valgrind from ports to check a C program for memory leaks. However, since recently (sorry, can't specify closer, within the last couple of months) I get a W^X violation when I try it. $ pwd /home/kk/Work/Development/MrBayes $ valgrind src/mb --80065:0:aspacem <<< SHOW_SEGMENTS: out_of_memory (21 segments, 0 segnames) --80065:0:aspacem0: RSVN 00-0003ff 64m - SmFixed --80065:0:aspacem1: 000400-0037ff832m --80065:0:aspacem2: ANON 003800-003835 3538944 r-x-- --80065:0:aspacem3: 003836-003845efff 1044480 --80065:0:aspacem4: FILE 003845f000-00384f4fff 614400 r d=0x000 i=0 o=3534848 (-1) --80065:0:aspacem5: 00384f5000-00385f4fff 1048576 --80065:0:aspacem6: FILE 00385f5000-00385fdfff 36864 rw--- d=0x000 i=0 o=4149248 (-1) --80065:0:aspacem7: ANON 00385fe000-00385fefff4096 rw--- --80065:0:aspacem8: 00385ff000-00386fdfff 1044480 --80065:0:aspacem9: FILE 00386fe000-00386fefff4096 rw--- d=0x000 i=0 o=4186112 (-1) --80065:0:aspacem 10: ANON 00386ff000-003a150fff 26m rw--- --80065:0:aspacem 11: 003a151000-0332374fff 12162m --80065:0:aspacem 12: ANON 0332375000-0332375fff4096 r-x-- --80065:0:aspacem 13: 0332376000-0801ff 19708m --80065:0:aspacem 14: RSVN 080200-0802000fff4096 - SmFixed --80065:0:aspacem 15: 0802001000-0f 32735m --80065:0:aspacem 16: RSVN 10-7f7ffdff9fff 130495g - SmFixed --80065:0:aspacem 17: ANON 7f7ffdffa000-7f7fffbf9fff 28m - --80065:0:aspacem 18: ANON 7f7fffbfa000-7f7f8fff 4190208 rw--- --80065:0:aspacem 19: ANON 7f7f9000-7f7f9fff4096 - --80065:0:aspacem 20: RSVN 7f7fa000- 16383e - SmFixed --80065:0:aspacem >>> --80065-- core:0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --80065-- dinfo :0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --80065-- (null) :0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 0 rzB --80065-- demangle:0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --80065-- ttaux :0/ 0 max/curr mmap'd, 0/0 unsplit/split sb unmmap'd, 0/ 0 max/curr, 0/ 0 totalloc-blocks/bytes, 0 searches 8 rzB --80065-- translate:fast SP updates identified: 0 ( --%) --80065-- translate: generic_known SP updates identified: 0 ( --%) --80065-- translate: generic_unknown SP updates identified: 0 ( --%) --80065-- tt/tc: 0 tt lookups requiring 0 probes --80065-- tt/tc: 0 fast-cache updates, 0 flushes --80065-- transtab: new0 (0 -> 0; ratio 0:10) [0 scs] --80065-- transtab: dumped 0 (0 -> ??) --80065-- transtab: discarded 0 (0 -> ??) --80065-- scheduler: 0 event checks. --80065-- scheduler: 0 indir transfers, 0 misses (1 in 0) --80065-- scheduler: 0/0 major/minor sched events. --80065--sanity: 0 cheap, 0 expensive checks. ==80065== ==80065== Valgrind's memory management: out of memory: ==80065==newSuperblock's request for 4194304 bytes failed. ==80065==64700416 bytes have already been allocated. ==80065== Valgrind cannot continue. Sorry. ==80065== ==80065== There are several possible reasons for this. ==80065== - You have some kind of memory limit in place. Look at the ==80065== output of 'ulimit -a'. Is there a limit on the size of ==80065== virtual memory or address space? ==80065== - You have run out of swap space. ==80065== - Valgrind has a bug. If you think this is the case or you are ==80065== not sure, please let us know and we'll try to fix it. ==80065== Please note that programs can take substantially more memory than ==80065== normal when running under Valgrind tools, eg. up to twice or ==80065== more, depending on the tool. On a 64-bit machine, Valgrind ==80065== should be able to make use of up 32GB memory. On a 32-bit ==80065== machine, Valgrind should be able to use all the memory available ==80065== to a single process, up to 4GB if that's how you have your ==80065== kernel configured. Most 32-bit Linux setups allow a maximum of ==80065== 3GB per process. ==80065== ==80065== Whatever the reason, Valgrind cannot continue. Sorry. $ dmesg | tail vscsi0 at root scsibus2 at vscsi0: 256 targets softraid0 at r