Just as a side note: PHP 7.1.2 was released like a week ago, and I have not seen any more spurious segfaults on my instances when doing imports or anything like that on the server. The arc liberate bug remains dead and I have not seen any more faults in arc either. Builds should now be available in most PHP 7.1 repositories (in multiple distros/systems), so I suggest an upgrade for anyone who's affected.

i'm bad at search

Yeah, 7.1.2 RC1 seems to fix the problems. There are like 2 dozen random "uuhh fix off by one error, revert thing that overflowed something, you bastard, fix this too" commits in that commit log, even some affecting stuff like libgd (which you'd think would have been pretty hardened), so it's really impossible to tell what fixed what without it becoming tedious.

In T12196#210013, @epriestley wrote:

PHP7.1 segfaults about a dozen times a day for me, every day, with little apparent rhyme or reason to the segfaults.

I can only assume I am being punished for not rushing it into production as soon as possible. Perhaps we can deploy PHP 7.2 to production directly from master without waiting for an actual release.

Awwwww yissssssss, looks like PHP 7.1.2 RC1 fixes it! Using the Fedora 25 "PHP 7.1 Remi Testing" repository, 7.1.2 just completely finished a run of arc liberate on Phabricator without problem.

Yeah, the sury repository is the one maintained by one of the PHP devs. I think if you just do something like apt remove php71* or apt remove php7.1* you can just reinstall all the php5.6 packages and you'll be dandy, at least as far as arc is concerned. They're all in the same repo, just separated by version suffix.

Just curious -- did you just notice this, or did you upgrade just to test this bug? If it was the first, that's an interesting data point! (that arc liberate is less common than I expected)

a devastating self-own. we've all owned ourselves.

Yup, that's the one @chad. I haven't tracked it down any further with strace or anything -- but if you try running that phutil_symbols.php command a billion times, note it doesn't fail every time, or possibly even at all (try like, for x in $(seq 1 1000); do php ... >/dev/null; echo $?; done | grep 1 or something). But if you run arc liberate again, it *will* fail every time, just on a different file, at a different point.

xhprof isn't needed to reproduce this; it's xhpast that's involved. Maybe. (xhpast is just a simple bison/flex parser/lexer combo so it isn't dependent on PHP internals in any way, and it's what drives the module parsing, etc)

i like that dog's hat. it's a good hat.

Ah, cool -- thanks!

FWIW, PHP 7.1.0 RC1 was released today, and it includes the async signal change. The following amended script from T11270#184087 seems to work:

Just as a note: I had this happen again on another very low-power instance (same file storage backend, encryption enabled etc), but with the latest HEAD, simply reloading with Ctrl+R after the webserver timed out the request made it continue and work perfectly. So yes, this is fixed it seems.

Thanks for listening to my hair-brained schemes. Yeah, the motivation is totally clear to me FWIW, and thinking about it more, I strongly suggest this is related to T9161.

In T10203#185476, @hach-que wrote:

Though it's worth pointing out CircleCI only supports 2 concurrent jobs at their highest tier, and 1 concurrent job for every other plan, so it's not suitable for a wide variety of purposes.

In T11307#185338, @epriestley wrote:

T10907 is also sort of adjacent.

I just wanted to add a vote of support for this (following up from here) - for Haskell.org Windows is one of the "Tier-1" platforms that we ship binaries for, and having continuous integration is exceedingly useful for a number of reasons.

Yeah, T8124 is definitely the error user-facing I saw when this occurred, except there's no possible way to edit your profile pic at that point as the exception takes up the whole page.

What I found interesting about this bug is, I've had some obvious high latency with this storage engine - but incremental storage uploads for large files work fantastic in every use case I've tried, e.g. cancelling requests and all kinds of stuff. I guess this 'magical' default profile picture creation can't use the 'resume upload' mechanics?

I updated my original answer (since I can't post a new one; I meant to add it as a comment on your original Q) with instructions on how to write the Herald rule you need, so you can accept that answer as "the accepted answer" for this Ponder.

In T8787#177689, @siepkes wrote:

My 2 cents; I wouldn't spent too much time on implementing various authentication schemes for Phabricator like Yubikey, U2F, password with SMS or whatever flavour of authentication comes out tomorrow. Since Phabricator supports OpenID such authentication schemes can easily be delegated to IAM solutions like GLUU, OpenAM, KeyCloak, etc.

Now it might be a good idea to make a tutorial showing how to install KeyCloak with Phabricator to get U2F support but actually trying to be an IAM seems like a waste of time and duplication of effort.

In T5000#176361, @thoughtpolice wrote:

The expectation is basically, "I want to contribute a typofix, and maybe some more later, but why I do I have to spend 20 extra minutes up front on my first patch, a typofix? Can't this be easier up front?" Note that GHC is a compiler so it inherently has a somewhat high activation energy; this is 20 minutes spent on top of the 20-40 minutes you spent already getting it to build, etc.

So in the case of Haskell.org, specifically the Glasgow Haskell Compiler (which I'll go ahead and put out there, since I believe we're the one who got this put on 'The Queue' in question), our root problem that we think this fixes, I believe, is not "Phabricator should act like GitHub" or "Phabricator should act like Gerrit", which aren't reasonable or actionable as requests. They're sometimes brought up, but not our real problem. Rather, it is "Contributing smaller changes carries lots of unnecessary friction, perhaps even psychologically, because of arcanist".

Yeah, should be restarted with my custom dumb script:

Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.

Actually, now that I think about it, the chunked representation overlays the underlying object storage system, so file.info by itself isn't enough - it needs to also extend file.querychunks.

I think adding it to conduit is a good compromise; there's very little that's useful in the UI, and if anyone complains about something it should be easy enough to pin just using file.info. file.info already is very short anyway, so adding a fileHandle field should be relatively kosher, I think.