Re: W^X issues running valgrind

[Stuart Henderson]

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

[Andreas Kusalananda Kähäri]

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

[Andreas Kusalananda Kähäri]

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

[Stuart Henderson]

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

[David Coppa]

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

[Andreas Kusalananda Kähäri]

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