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:aspacem    0: RSVN 0000000000-0003ffffff     64m ----- SmFixed
--80065:0:aspacem    1:      0004000000-0037ffffff    832m
--80065:0:aspacem    2: ANON 0038000000-003835ffff 3538944 r-x--
--80065:0:aspacem    3:      0038360000-003845efff 1044480
--80065:0:aspacem    4: FILE 003845f000-00384f4fff  614400 r---- d=0x000 i=0
o=3534848 (-1)
--80065:0:aspacem    5:      00384f5000-00385f4fff 1048576
--80065:0:aspacem    6: FILE 00385f5000-00385fdfff   36864 rw--- d=0x000 i=0
o=4149248 (-1)
--80065:0:aspacem    7: ANON 00385fe000-00385fefff    4096 rw---
--80065:0:aspacem    8:      00385ff000-00386fdfff 1044480
--80065:0:aspacem    9: FILE 00386fe000-00386fefff    4096 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-0332375fff    4096 r-x--
--80065:0:aspacem   13:      0332376000-0801ffffff  19708m
--80065:0:aspacem   14: RSVN 0802000000-0802000fff    4096 ----- SmFixed
--80065:0:aspacem   15:      0802001000-0fffffffff  32735m
--80065:0:aspacem   16: RSVN 1000000000-7f7ffdff9fff 130495g ----- SmFixed
--80065:0:aspacem   17: ANON 7f7ffdffa000-7f7fffbf9fff     28m -----
--80065:0:aspacem   18: ANON 7f7fffbfa000-7f7fffff8fff 4190208 rw---
--80065:0:aspacem   19: ANON 7f7fffff9000-7f7fffff9fff    4096 -----
--80065:0:aspacem   20: RSVN 7f7fffffa000-ffffffffffffffff  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: new        0 (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 root
scsibus3 at softraid0: 256 targets
root on wd0a (22d20e8d1f94fa20.a) swap on wd0b dump on wd0b
memcheck-amd64-o(80678): mmap W^X violation
memcheck-amd64-o(85292): mmap W^X violation
memcheck-amd64-o(46575): mmap W^X violation
memcheck-amd64-o(27486): mmap W^X violation
memcheck-amd64-o(80065): mmap W^X violation

I've added wxallowed to /home, but that doesn't help (will remove it
again).  I get the same behaviour from valgrind regardless of whether
wxallowed is set or not on the partition holding the executable I'd like
to run. wxallowed is set on /usr/local where the valgrind executable
lives:

$ mount
/dev/wd0a on / type ffs (local)
/dev/wd0d on /home type ffs (local, nodev, nosuid, wxallowed)
/dev/wd0e on /usr type ffs (local, nodev, softdep)
/dev/wd0f on /usr/local type ffs (local, nodev, wxallowed, softdep)
/dev/wd0g on /usr/ports type ffs (local, nodev, nosuid, wxallowed, softdep)
/dev/wd0h on /var type ffs (local, nodev, nosuid)

Do I need to add wxallowed to any other partition to be able to use
valgrind properly?

Full dmesg (this is a VirtualBox host):

OpenBSD 6.0-current (GENERIC.MP) #52: Thu Oct  6 08:11:57 CEST 2016
    kk@uerfale:/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278124544 (4079MB)
avail mem = 4143972352 (3952MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.5 @ 0xe1000 (10 entries)
bios0: vendor innotek GmbH version "VirtualBox" date 12/01/2006
bios0: innotek GmbH VirtualBox
acpi0 at bios0: rev 2
acpi0: sleep states S0 S5
acpi0: tables DSDT FACP APIC SSDT
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimadt0 at acpi0 addr 0xfee00000: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3193.11 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES
,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: CPU supports MTRRs but not enabled by BIOS
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz, 3192.80 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES
,XSAVE,AVX,RDRAND,NXE,LONG,LAHF,ABM,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec00000, version 11, 24 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!)
acpicpu1 at acpi0: C1(@1 halt!)
"PNP0303" at acpi0 not configured
"PNP0F03" at acpi0 not configured
acpiac0 at acpi0: AC unit online
acpivideo0 at acpi0: GFX0
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
pciide0 at pci0 dev 1 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: <VBOX HARDDISK>
wd0: 128-sector PIO, LBA, 51200MB, 104857600 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: <VBOX, CD-ROM, 1.0> ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
vga1 at pci0 dev 2 function 0 "InnoTek VirtualBox Graphics Adapter" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
em0 at pci0 dev 3 function 0 "Intel 82543GC" rev 0x02: apic 2 int 19, address
08:00:27:b1:89:72
"InnoTek VirtualBox Guest Service" rev 0x00 at pci0 dev 4 function 0 not
configured
piixpm0 at pci0 dev 7 function 0 "Intel 82371AB Power" rev 0x08: SMBus
disabled
em1 at pci0 dev 8 function 0 "Intel 82543GC" rev 0x02: apic 2 int 16, address
08:00:27:ff:fb:ca
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5 irq 1 irq 12
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on wd0a (22d20e8d1f94fa20.a) swap on wd0b dump on wd0b
memcheck-amd64-o(80678): mmap W^X violation
memcheck-amd64-o(85292): mmap W^X violation
memcheck-amd64-o(46575): mmap W^X violation
memcheck-amd64-o(27486): mmap W^X violation
memcheck-amd64-o(80065): mmap W^X violation
memcheck-amd64-o(83826): mmap W^X violation

--
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]

Reply via email to