Joshua M. Clulow writes: > On 23 June 2015 at 14:11, Ryan Zezeski <[email protected]> wrote: >> 2) I decided to try to build 4.0.2.4 but with the alternate signal stack >> disabled. But the build got stock. Interesting enough it got stuck in >> the same place before when I was writing my original report but after >> sitting there for a few minutes it eventually kicked itself free (or >> maybe me poking around caused it to unstick). Anyways, I wrote up a >> report of what I saw: >> >> https://gist.github.com/rzezeski/8a967f9cfdd3976869eb#comment-1479293 > > When the native tools tell you the program is blocked in "SYS#0", > that's an artefact of the way Linux system calls are handled by LX. > If you look at the kernel stack for that LWP, you will likely see > where it's actually blocked in the kernel. The inflight Linux system > call number is also stashed in "br_syscall_num" of the "lx_lwp_data_t" > for that LWP (which is pointed to by "lwp_brand" on the "klwp_t").
This was a big help! Thank you. I have another stuck build and it looks like the futex implementation may be the culprit. I will run more tests to verify futex is always invovled when stuck. Here is my latest report: https://gist.github.com/rzezeski/8a967f9cfdd3976869eb#comment-1479375 -- -Z ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
