🙉

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.

I think we currently don't really try to handle these cases:

That tip probably does not fit on screen in any of the orientations: it obviously won't fit to the north or east. If we try to put it to the south, part of it will be offscreen to the right. If we try to put it to the west, part of it will be off the top of the screen (the rectangle we use to detect the size of the tip box is slightly larger than the actual pixel size of the tip because we get weird scrollbar interactions if we use the size of the tip exactly).

My trick is:

Yeah I couldn't quite grab a screen

Here's what I see:

Chrome:

• Go to Workboard
• Click Fullscreen
• Hover over Fullscreen - tooltip is elsewhere?

This should now be resolved at HEAD of master, and should promote to stable later today.

Gotcha... Thanks for the explanation. Initially, I wasn't exactly sure what was going on... I sent an email out telling folks to use "Auditor: ..." in their commit messages, upgraded to clean up what I mentioned here T12181: Bulk Deleting Audits does not remove "Audit Required" from Commit, and then the "Auditor: ..." tag stopped working when our team started using it. Appreciate the fix!

Thanks! I think this is the timeline of events:

Ahhh... Before both "Auditor: ..." and "Auditors: ..." worked. Now it appears that only "Auditors: ..." works. I must not have been trying it with "Auditors: ..." at all.

Per above, it sounds like upgrading fixed what you were seeing?

No, not yet... In those examples, I just happened to have Auditors on the first line. Usually, it's not on the first line for us.

Does that explain what you're seeing locally?

Those commits are not expected to trigger an audit after D17122 / T10312. The first line of commit messages is now always parsed as a title, even if it begins "Auditors: ...", "Tests: ...", "Reviewers: ...", etc.

Is there a full description or is it a joke? I need to do my case study on tasks that contain errors. I guess that is some empty task that was deleted by the creator immediately.
Will buy case study anyway, no point in looking for phantoms here.

@epriestley can you have a look at this, please?

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.

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

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.

I updated to test this bug. I'll have to roll back if I need to add a new class.

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.

well i've ruined my dev environment now...

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)

like this:

T9805?

We need a neologism for "bad workaround".

(A "workaround" is to not use dashboards, but we'll fix this soon.)

Ah, cool -- thanks!

See T12174 -- this is an issue with the new embedded-on-Home dashboards.

word-break: break-all; seems to be working fine.

I can't reproduce this, is there a specific browser/OS I should test? Also, feel free to upload a test file to rGITTEST

The linked file was used for testing this bug in a repeatable way. Based on some internal testing my (very rough) estimate is that this occurs with commits that are at least above the 750MB mark. I haven't tested below this size, but some more debugging could be done to try and find the limit and to confirm that it's related to commit sizes rather than some other metric like time.

• For HTTP, this is broadly expected in some sense until T4369 is resolved.
• For SSH, this is not expected but the linked file is 1.75GB. Did you encounter this in a more realistic scenario and the size of that file is just for demonstration purposes, or are you trying to store ~1GB binary assets in a Git repository? Git is generally not well suited to serve as a binary asset store. GitLFS (T7789) or possible future changes like T11367 are likely better fits for this use case.

First of all: thank you again for the quick response and great work!

In 99% of cases, the right thing to do when you see an error in the daemon logs is:

@epriestley: Was deleting the active task the right way or did I broke my database or relations?

We can only accept bug reports against current versions of Phabricator, as detailed in Contributing Bug Reports. Feel free to file a new report against a modern version, if this issue still reproduces at HEAD of master or stable.

Yeah, run bin/audit synchronize --all (or rXYZ for just one repository) after doing manual cleanup with bin/audit delete. This is noted in the documentation at HEAD as of ~yesterday, although it may not have regenerated in production yet.

Realized this is probably solved by rPaca0f642a3bdaa602bde05abfe94f9d90cf7b06e. Will switch to master.