Port-i386 archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: modular/pkgsrc Xorg on netbsd-8, -current i386 stuck in "fdclose"
On Sat, 19 Aug 2017, John D. Baker wrote:
> The 'ktruss' output shows just what I expected. It's the same as
> reported in the previously-cited PR:
>
> [...]
> 136 1 Xorg open("/usr/pkg/lib/libGL.so.1", 0, 0xb4192cf7) = 9
> 136 1 Xorg __fstat50(0x9, 0xbfb786f0) = 0
> 136 1 Xorg mmap(0, 0x1000, 0x1, 0x1, 0x9, 0, 0, 0) = 0xb418e000
> 136 1 Xorg munmap(0xb418e000, 0x1000) = 0
> 136 1 Xorg mmap(0, 0x67000, 0x5, 0x2, 0x9, 0, 0, 0) = 0xb4128000
> 136 1 Xorg mmap(0xb4181000, 0xe000, 0x7, 0x12, 0x9, 0, 0x58000, 0) Err#13 EACCES
> 136 1 Xorg munmap(0xb4128000, 0x67000) = 0
As mentioned in the PR, the third mmap() call is requesting an RWX
mapping. This is now the third time I've seen this pattern, in
"qt3-tool"'s 'uic' tool, 'mplayer' and now pkgsrc/modular 'Xorg'.
In all cases, this RWX mmap() request happens immdiately after opening
"/usr/pkg/lib/libGL.so.1". (I.e., it only affects modular/pkgsrc Xorg.)
I tried to run 'Xorg' under 'gdb', and set a breakpoint on mmap(), but
it segfaulted upon creating a new thread before reaching the RWX mmap()
call.
Perhaps I'll try again with 'mplayer' or 'uic' to figure out from where
the RWX mmap() call is coming.
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Home |
Main Index |
Thread Index |
Old Index