lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 06 Mar 2009 02:55:21 +0000
From:	Sid Boyce <g3vbv@...eyonder.co.uk>
To:	Darren Hart <dvhltc@...ibm.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Strange problem with FUTEX_WAIT_PRIVATE

Darren Hart wrote:
> Sid Boyce wrote:
>> I don't know if it's a kernel problem, I have already posted to openSUSE
>> Factory list without any response. It's either an openSUSE problem or
>> one encountered since about 2.6.29-rc4 I'd guess and through to
>> 2.6.29-rc7-git1.
>> If I execute certain applications as root I never get the GUI output, as
>> user everything works as expected.
>> Below is part of the strace output from "qjackctl". VirtualBox  and
>> others do the same.
>> <<<Previous lines deleted>>
>> stat("/etc/kde4/share/config/oxygenrc", {st_mode=S_IFREG|0644,
>> st_size=55, ...}) = 0
>> stat("/etc/kde4/share/config/oxygenrc", {st_mode=S_IFREG|0644,
>> st_size=55, ...}) = 0
>> fstat(8, {st_mode=S_IFREG|0644, st_size=55, ...}) = 0
>> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
>> = 0x7fba0d1a9000
>> read(8, "[Windeco]\nBlendTitlebarColors=false\nShowStripes=false\n\n",
>> 4096) = 55
>> read(8, "", 4096)                       = 0
>> close(8)                                = 0
>> munmap(0x7fba0d1a9000, 4096)            = 0
>> socket(PF_FILE, SOCK_STREAM, 0)         = 8
>> connect(8, {sa_family=AF_FILE, path=@"/tmp/dbus-8XYkB058j7"}, 23) = 0
>> fcntl(8, F_GETFL)                       = 0x2 (flags O_RDWR)
>> fcntl(8, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
>> fcntl(8, F_GETFD)                       = 0
>> fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
>> geteuid()                               = 0
>> rt_sigaction(SIGPIPE, {0x1, [PIPE], SA_RESTORER|SA_RESTART,
>> 0x7fba0869d6e0}, {SIG_DFL, [], 0}, 8) = 0
>> poll([{fd=8, events=POLLOUT}], 1, 0)    = 1 ([{fd=8, revents=POLLOUT}])
>> write(8, "\0", 1)                       = 1
>> write(8, "AUTH EXTERNAL 30\r\n", 18)    = 18
>> poll([{fd=8, events=POLLIN}], 1, -1)    = 1 ([{fd=8, revents=POLLIN}])
>> read(8, "OK 7c5d389345212834a5f2258649afe483\r\n", 2048) = 37
>> poll([{fd=8, events=POLLOUT}], 1, -1)   = 1 ([{fd=8, revents=POLLOUT}])
>> write(8, "BEGIN\r\n", 7)                = 7
>> poll([{fd=8, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=8,
>> revents=POLLIN|POLLOUT|POLLHUP}])
>> read(8, "", 2048)                       = 0
>> close(8)                                = 0
>> sched_yield()                           = 0
>> sched_yield()                           = 0
>> sched_yield()                           = 0
>> sched_yield()                           = 0
>> <<< many lines of the same truncated>>>
>> sched_yield()                           = 0
>> sched_yield()                           = 0
> 
> tsk tsk tsk
> 
>> futex(0x7722ac, FUTEX_WAIT_PRIVATE, 1, NULL
>>
>> It never moves beyond that point and I have to CTRL-C back to the prompt.
>> Regards
>> Sid.
> 
> So without an accompanying FUTEX_WAKE this thread will never return
> (since the timeout is NULL).  I suggest 'strace -f' to follow all
> threads - do you see the FUTEX_WAKE?  Do you see it when not running as
> root?
> 
It was run with "strace -s 256 -f" and FUTEX_WAKE occurs earlier in the
strace, it just hangs on the last one. Attaching the full strace output.
Regards
Sid.
-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

View attachment "QJ.out" of type "text/plain" (181682 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ