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