Hhvm: HHVM 3.30.3 crashes when attempting to build a repo

[aishraj]

HHVM Version

/usr/bin/hhvm --version
HipHop VM 3.30.3 (rel)
Compiler: remotes/origin/3.30.3-slack-0-g27cca4072e01a09c69296a1597fc3811fbb21ca9
Repo schema: 0808366c931ad94ec0c7048c69a2eb4589e2aa67

Operating System and Version

Ubuntu 16.04.5 LTS (Xenial Xerus)

Standalone code, or other way to reproduce the problem

Attempt to build repo auth the following way

$ hvm --hphp -o /tmp/raresult -t hhbc -v AllVolatile=true --input-dir /path/to/source
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (4 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (6 us) wall time
analyzeProgram took 0'00" (42 us) wall time
parsing inputs took 0'55" (55569421 us) wall time
analyze final...
analyze final took 0'00" (3 us) wall time
creating binary HHBC files...
running HHBBC...
committing units to repo...
Core dumped: Segmentation fault
Stack trace in /tmp/stacktrace.28229.log
hphp failed
running hphp took 2'24" (144489590 us) wall time

Actual result

As seen above, we see a segfault

Expected result

The repo-auth build completes without errors

Debug info

On running the above under gdb we see:

(gdb) run --hphp --coredump=0 -o /tmp/ard_repo -t hhbc -v AllVolatile=true --input-dir /path/to/source
Starting program: /usr/bin/hhvm --hphp --coredump=0 -o /tmp/ard_repo -t hhbc -v AllVolatile=true --input-dir /path/to/source
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
running hphp...
[New Thread 0x7fffe3fff700 (LWP 27619)]
parsing inputs...
[New Thread 0x7fffde3ff700 (LWP 27625)]
[New Thread 0x7fffda3ff700 (LWP 27626)]
[New Thread 0x7fffd67ff700 (LWP 27628)]
analyzeProgram...
[Thread 0x7fffda3ff700 (LWP 27626) exited]
analyze all...
analyze all took 0'00" (5 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (2 us) wall time
[Thread 0x7fffde3ff700 (LWP 27625) exited]
analyzeProgram took 0'00" (42 us) wall time
parsing inputs took 0'53" (53602716 us) wall time
analyze final...
analyze final took 0'00" (2 us) wall time
creating binary HHBC files...
[New Thread 0x7fffb43ff700 (LWP 29096)]
running HHBBC...
[New Thread 0x7fffb0bfe700 (LWP 29097)]
[New Thread 0x7fffad3fd700 (LWP 29098)]
[Thread 0x7fffad3fd700 (LWP 29098) exited]
[Thread 0x7fffb0bfe700 (LWP 29097) exited]
[New Thread 0x7fffad3fd700 (LWP 29110)]
[New Thread 0x7fffb0bfe700 (LWP 29111)]
[Thread 0x7fffb0bfe700 (LWP 29111) exited]
[Thread 0x7fffad3fd700 (LWP 29110) exited]
[New Thread 0x7fffb0bfe700 (LWP 29112)]
[New Thread 0x7fffad3fd700 (LWP 29113)]
[Thread 0x7fffad3fd700 (LWP 29113) exited]
[Thread 0x7fffb0bfe700 (LWP 29112) exited]
[New Thread 0x7fffad3fd700 (LWP 29114)]
[New Thread 0x7fffb0bfe700 (LWP 29115)]
[Thread 0x7fffb0bfe700 (LWP 29115) exited]
[Thread 0x7fffad3fd700 (LWP 29114) exited]
[New Thread 0x7fffb0bfe700 (LWP 29116)]
[New Thread 0x7fffad3fd700 (LWP 29117)]
[Thread 0x7fffad3fd700 (LWP 29117) exited]
[Thread 0x7fffb0bfe700 (LWP 29116) exited]
[New Thread 0x7fffad3fd700 (LWP 29118)]
[New Thread 0x7fffb0bfe700 (LWP 29119)]
[Thread 0x7fffad3fd700 (LWP 29118) exited]
[Thread 0x7fffb0bfe700 (LWP 29119) exited]
[New Thread 0x7fffb0bfe700 (LWP 29122)]
[New Thread 0x7fffad3fd700 (LWP 29123)]
[Thread 0x7fffad3fd700 (LWP 29123) exited]
[Thread 0x7fffb0bfe700 (LWP 29122) exited]
[New Thread 0x7fffad3fd700 (LWP 29124)]
[New Thread 0x7fffb0bfe700 (LWP 29125)]
[Thread 0x7fffb0bfe700 (LWP 29125) exited]
[Thread 0x7fffad3fd700 (LWP 29124) exited]
[New Thread 0x7fffb0bfe700 (LWP 29126)]
[New Thread 0x7fffad3fd700 (LWP 29127)]
[Thread 0x7fffad3fd700 (LWP 29127) exited]
[Thread 0x7fffb0bfe700 (LWP 29126) exited]
[New Thread 0x7fffad3fd700 (LWP 29128)]
[New Thread 0x7fffb0bfe700 (LWP 29129)]
[Thread 0x7fffb0bfe700 (LWP 29129) exited]
[Thread 0x7fffad3fd700 (LWP 29128) exited]
[New Thread 0x7fffb0bfe700 (LWP 29130)]
[New Thread 0x7fffad3fd700 (LWP 29131)]
[Thread 0x7fffb0bfe700 (LWP 29130) exited]
[Thread 0x7fffad3fd700 (LWP 29131) exited]
[New Thread 0x7fffad3fd700 (LWP 29132)]
[New Thread 0x7fffb0bfe700 (LWP 29133)]
[Thread 0x7fffb0bfe700 (LWP 29133) exited]
[Thread 0x7fffad3fd700 (LWP 29132) exited]
[New Thread 0x7fffb0bfe700 (LWP 29134)]
[New Thread 0x7fffad3fd700 (LWP 29135)]
[Thread 0x7fffad3fd700 (LWP 29135) exited]
[Thread 0x7fffb0bfe700 (LWP 29134) exited]
[New Thread 0x7fffad3fd700 (LWP 29136)]
[New Thread 0x7fffb0bfe700 (LWP 29137)]
[Thread 0x7fffb0bfe700 (LWP 29137) exited]
[Thread 0x7fffad3fd700 (LWP 29136) exited]
[New Thread 0x7fffb0bfe700 (LWP 29138)]
[New Thread 0x7fffad3fd700 (LWP 29139)]
[Thread 0x7fffad3fd700 (LWP 29139) exited]
[Thread 0x7fffb0bfe700 (LWP 29138) exited]
[New Thread 0x7fffad3fd700 (LWP 29140)]
[New Thread 0x7fffb0bfe700 (LWP 29141)]
[Thread 0x7fffad3fd700 (LWP 29140) exited]
[Thread 0x7fffb0bfe700 (LWP 29141) exited]
[New Thread 0x7fffb0bfe700 (LWP 29142)]
[New Thread 0x7fffad3fd700 (LWP 29143)]
[Thread 0x7fffb0bfe700 (LWP 29142) exited]
[Thread 0x7fffad3fd700 (LWP 29143) exited]
[New Thread 0x7fffad3fd700 (LWP 29149)]
[New Thread 0x7fffb0bfe700 (LWP 29150)]
[Thread 0x7fffb0bfe700 (LWP 29150) exited]
[Thread 0x7fffad3fd700 (LWP 29149) exited]
[New Thread 0x7fffb0bfe700 (LWP 29683)]
[New Thread 0x7fffad3fd700 (LWP 29684)]
[Thread 0x7fffb0bfe700 (LWP 29683) exited]
[Thread 0x7fffad3fd700 (LWP 29684) exited]
[New Thread 0x7fffad3fd700 (LWP 29698)]
[New Thread 0x7fffb0bfe700 (LWP 29699)]
[Thread 0x7fffad3fd700 (LWP 29698) exited]
[Thread 0x7fffb0bfe700 (LWP 29699) exited]
[New Thread 0x7fffb0bfe700 (LWP 29732)]
[New Thread 0x7fffad3fd700 (LWP 29733)]
[Thread 0x7fffb0bfe700 (LWP 29732) exited]
[Thread 0x7fffad3fd700 (LWP 29733) exited]
[New Thread 0x7fffad3fd700 (LWP 29734)]
[New Thread 0x7fffb0bfe700 (LWP 29735)]
[Thread 0x7fffb0bfe700 (LWP 29735) exited]
[Thread 0x7fffad3fd700 (LWP 29734) exited]
[New Thread 0x7fffb0bfe700 (LWP 29740)]
[New Thread 0x7fffad3fd700 (LWP 29741)]
[Thread 0x7fffb0bfe700 (LWP 29740) exited]
[Thread 0x7fffad3fd700 (LWP 29741) exited]
[New Thread 0x7fffad3fd700 (LWP 29742)]
[New Thread 0x7fffb0bfe700 (LWP 29743)]
[Thread 0x7fffad3fd700 (LWP 29742) exited]
[Thread 0x7fffb0bfe700 (LWP 29743) exited]
[New Thread 0x7fffb0bfe700 (LWP 29744)]
[New Thread 0x7fffad3fd700 (LWP 29745)]
[Thread 0x7fffb0bfe700 (LWP 29744) exited]
[Thread 0x7fffad3fd700 (LWP 29745) exited]
[New Thread 0x7fffad3fd700 (LWP 29746)]
[New Thread 0x7fffb0bfe700 (LWP 29747)]
[Thread 0x7fffb0bfe700 (LWP 29747) exited]
[Thread 0x7fffad3fd700 (LWP 29746) exited]
[New Thread 0x7fffb0bfe700 (LWP 29748)]
[New Thread 0x7fffad3fd700 (LWP 29749)]
[Thread 0x7fffad3fd700 (LWP 29749) exited]
[Thread 0x7fffb0bfe700 (LWP 29748) exited]
[New Thread 0x7fffad3fd700 (LWP 29752)]
[New Thread 0x7fffb0bfe700 (LWP 29753)]
[Thread 0x7fffb0bfe700 (LWP 29753) exited]
[Thread 0x7fffad3fd700 (LWP 29752) exited]
[New Thread 0x7fffb0bfe700 (LWP 29760)]
[New Thread 0x7fffad3fd700 (LWP 29761)]
[Thread 0x7fffb0bfe700 (LWP 29760) exited]
[Thread 0x7fffad3fd700 (LWP 29761) exited]
[New Thread 0x7fffad3fd700 (LWP 29762)]
[New Thread 0x7fffb0bfe700 (LWP 29763)]
[Thread 0x7fffb0bfe700 (LWP 29763) exited]
[Thread 0x7fffad3fd700 (LWP 29762) exited]
[New Thread 0x7fffb0bfe700 (LWP 29764)]
[New Thread 0x7fffad3fd700 (LWP 29765)]
[Thread 0x7fffad3fd700 (LWP 29765) exited]
[Thread 0x7fffb0bfe700 (LWP 29764) exited]
[New Thread 0x7fffad3fd700 (LWP 29766)]
[New Thread 0x7fffb0bfe700 (LWP 29767)]
[Thread 0x7fffb0bfe700 (LWP 29767) exited]
[Thread 0x7fffad3fd700 (LWP 29766) exited]
[New Thread 0x7fffb0bfe700 (LWP 29768)]
[New Thread 0x7fffad3fd700 (LWP 29769)]

Thread 72 "hhvm" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffad3fd700 (LWP 29769)]
0x00007ffff7bbf8af in ?? () from /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
(gdb) bt
#0  0x00007ffff7bbf8af in ?? () from /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
#1  0x00007ffff7ba43cd in free () from /usr/lib/x86_64-linux-gnu/libjemalloc.so.1
#2  0x00000000011ba79f in std::_Rb_tree<HPHP::HHBBC::(anonymous namespace)::InstrId, std::pair<HPHP::HHBBC::(anonymous namespace)::InstrId const, HPHP::HHBBC::(anonymous namespace)::DceAction>, std::_Select1st<std::pair<HPHP::HHBBC::(anonymous namespace)::InstrId const, HPHP::HHBBC::(anonymous namespace)::DceAction> >, std::less<HPHP::HHBBC::(anonymous namespace)::InstrId>, std::allocator<std::pair<HPHP::HHBBC::(anonymous namespace)::InstrId const, HPHP::HHBBC::(anonymous namespace)::DceAction> > >::clear() ()
#3  0x00000000012428e7 in HPHP::HHBBC::global_dce(HPHP::HHBBC::Index const&, HPHP::HHBBC::FuncAnalysis const&) ()
#4  0x00000000010918fe in HPHP::HHBBC::(anonymous namespace)::do_optimize(HPHP::HHBBC::Index const&, HPHP::HHBBC::FuncAnalysis&&, bool) ()
#5  0x0000000001093ffc in HPHP::HHBBC::optimize_func(HPHP::HHBBC::Index const&, HPHP::HHBBC::FuncAnalysis&&, bool) ()
#6  0x0000000000e5cecb in HPHP::HHBBC::(anonymous namespace)::final_pass(HPHP::HHBBC::Index&, HPHP::HHBBC::php::Program&)::{lambda(HPHP::HHBBC::Context)#1}::operator()(HPHP::HHBBC::Context) const ()
#7  0x0000000000e5d56f in std::thread::_Impl<std::_Bind_simple<void HPHP::HHBBC::parallel::for_each<HPHP::HHBBC::(anonymous namespace)::final_pass(HPHP::HHBBC::Index&, HPHP::HHBBC::php::Program&)::{lambda(HPHP::HHBBC::Context)#1}, HPHP::HHBBC::Context>(std::vector<HPHP::HHBBC::Context, std::allocator<std::vector> > const&, HPHP::HHBBC::(anonymous namespace)::final_pass(HPHP::HHBBC::Index&, HPHP::HHBBC::php::Program&)::{lambda(HPHP::HHBBC::Context)#1})::{lambda()#1} ()> >::_M_run() ()
#8  0x00007ffff0121c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x00007ffff5b9a6ba in start_thread (arg=0x7fffad3fd700) at pthread_create.c:333
#10 0x00007fffef88741d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

Note that while it does seem like it was fixed here: https://github.com/facebook/hhvm/issues/8395#issuecomment-459782943 we're still seeing seeing seg faults.

[fredemmott]

is there any chance you can reduce the repo to some smaller, shareable code that reproduces the problem?

[aishraj]

Sure, I'll try to run it on a smaller code and see if I can repro the problem.

Another piece of info that I missed in the original description is that I was able to successfully build the repo on my local Macbook running the same HHVM version. Not sure if that's a smoking gun but thought I should mention it here.

[fredemmott]

Try adding —no-config at the start of the command line

[aishraj]

Running hhvm --no-config --hphp -o /tmp/raresult_no_config2 -t hhbc -v AllVolatile=true --input-dir /path results in
Error in command line: unrecognised option '--hphp' followed by the help message.

[ssandler]

I tried on 4.0.2 and was able to repro a segfault as well with our codebase. To make sure it wasn't our build, I also did this using sudo apt-get install hhvm=4.0.2-1~xenial.

Tried doing one subfolder at a time, and to my surprise it happens on facebook/difflib.

$ hhvm --version
HipHop VM 4.0.2 (rel)
Compiler: 1550604588_834029057
Repo schema: 3d728ec7b36d0e4c22fa809b10e60be6ced45939

```$ hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /path/to/repo/vendor/facebook/difflib/
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (3 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (1 us) wall time
analyzeProgram took 0'00" (38 us) wall time
parsing inputs took 0'00" (43905 us) wall time
analyze final...
analyze final took 0'00" (4 us) wall time
creating binary HHBC files...
running HHBBC...

---------------------------------optimize_func----------------------------------
Optimizing:Facebook\DiffLibmd5-7965a53144da43c3482f0ffa8f57f428Diff::getUnifiedDiff
Core dumped: Segmentation fault
Stack trace in /tmp/stacktrace.26356.log
hphp failed
running hphp took 0'01" (1599199 us) wall time
```

This appears to be the same issue as #8395 actually - it's crashing anywhere there is a ??= token in the source code. I was able to repro on some other functions/folders containing that token as well. No segfault when targeting other directories such as facebook/xhp-lib which don't contain the ??= token.

[ssandler]

Also easy to repro with docker:

$ docker pull hhvm/hhvm
Using default tag: latest
latest: Pulling from hhvm/hhvm
6cf436f81810: Pull complete 
987088a85b96: Pull complete 
b4624b3efe06: Pull complete 
d42beb8ded59: Pull complete 
04aa7fceb3e6: Pull complete 
Digest: sha256:b5efb83199b535db6a3054ac3eb9e8d30b84a5d16c147f70191ee3cd6195f34c
Status: Downloaded newer image for hhvm/hhvm:latest

$ docker run --tty --interactive hhvm/hhvm:latest /bin/bash -l
root@2a244fb2ad1e:/# hhvm --version
HipHop VM 4.0.2 (rel)
Compiler: 1550605031_606999898
Repo schema: a46021ba5e51d676a396f711ef442e334fa9152a

root@2a244fb2ad1e:/# cd /tmp

root@2a244fb2ad1e:/tmp# git clone https://github.com/hhvm/difflib.git
Cloning into 'difflib'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 179 (delta 13), reused 23 (delta 10), pack-reused 144
Receiving objects: 100% (179/179), 60.24 KiB | 5.02 MiB/s, done.
Resolving deltas: 100% (72/72), done.
root@2a244fb2ad1e:/tmp# hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /tmp/difflib
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (11 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (10 us) wall time
analyzeProgram took 0'00" (68 us) wall time
parsing inputs took 0'00" (49686 us) wall time
analyze final...
analyze final took 0'00" (11 us) wall time
creating binary HHBC files...
running HHBBC...

---------------------------------optimize_func----------------------------------
Optimizing:Facebook\DiffLib\StringDiff::getUnifiedDiff
Core dumped: Segmentation fault
Stack trace in /tmp/stacktrace.112.log
hphp failed
running hphp took 0'01" (1883385 us) wall time

[ssandler]

No repro on the hhvm/hhvm:nightly docker container though. Perhaps whatever fixed this issue for nightlies wasn't actually cherry picked into 3.30.3 and 4.0.2?

[fredemmott]

so, the previous issue was reproducible with the HSL, and I can't reproduce this with the HSL; this is probably a different issue with similar root cause and symptoms

Probably best to bisect to a day using the docker nightlies then it'll be quick to bisect through to that.

If you don't get to it sooner, I can take a look once I've finished look into today's mac build breakages :(

[fredemmott]

The fix for the previous issue was in January, before the 4.0 branch cut - it didn't need cherry-picking.

[ssandler]

The issue goes back surprisingly far! I repro'd on several docker nightlies from January and December. Looks like it was introduced on November 4th.

November 3rd, no segfault

$ docker run --tty --interactive hhvm/hhvm:2018.11.03 /bin/bash -l
Unable to find image 'hhvm/hhvm:2018.11.03' locally
2018.11.03: Pulling from hhvm/hhvm
18d680d61657: Already exists 
0addb6fece63: Already exists 
78e58219b215: Already exists 
eb6959a66df2: Already exists 
d0d5fa83d803: Pull complete 
Digest: sha256:4fb765532ea825564c64f75693a9e456063a762d883370a7c45220774947254e
Status: Downloaded newer image for hhvm/hhvm:2018.11.03
root@ad07ea462e72:/# cd /tmp && git clone https://github.com/hhvm/difflib.git && hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /tmp/difflib
Cloning into 'difflib'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 179 (delta 13), reused 23 (delta 10), pack-reused 144
Receiving objects: 100% (179/179), 60.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (72/72), done.
Checking connectivity... done.
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (11 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (9 us) wall time
analyzeProgram took 0'00" (91 us) wall time
parsing inputs took 0'00" (69820 us) wall time
analyze final...
analyze final took 0'00" (11 us) wall time
creating binary HHBC files...
running HHBBC...
committing units to repo...
running HHBBC took 0'00" (469823 us) wall time
committing units to repo took 0'00" (114326 us) wall time
creating binary HHBC files took 0'00" (520527 us) wall time
all files saved in /tmp/raresult ...
running hphp took 0'02" (2235215 us) wall time
root@ad07ea462e72:/tmp# logout

November 4th, segfault

$ docker run --tty --interactive hhvm/hhvm:2018.11.04 /bin/bash -l
Unable to find image 'hhvm/hhvm:2018.11.04' locally
2018.11.04: Pulling from hhvm/hhvm
18d680d61657: Already exists 
0addb6fece63: Already exists 
78e58219b215: Already exists 
eb6959a66df2: Already exists 
4f95fa2bba32: Pull complete 
Digest: sha256:a242aeecf7bd8748872b3a610b2ef73be48e7bc6f8a4b7f10e3c8bbf40f91cf1
Status: Downloaded newer image for hhvm/hhvm:2018.11.04
root@1b7bdc0486e1:/# cd /tmp && git clone https://github.com/hhvm/difflib.git && hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /tmp/difflib
Cloning into 'difflib'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 179 (delta 13), reused 23 (delta 10), pack-reused 144
Receiving objects: 100% (179/179), 60.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (72/72), done.
Checking connectivity... done.
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (12 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (9 us) wall time
analyzeProgram took 0'00" (68 us) wall time
parsing inputs took 0'00" (67985 us) wall time
analyze final...
analyze final took 0'00" (12 us) wall time
creating binary HHBC files...
running HHBBC...

---------------------------------optimize_func----------------------------------
Optimizing:Facebook\DiffLib\StringDiff::getUnifiedDiff
Core dumped: Segmentation fault
Stack trace in /tmp/stacktrace.27.log
hphp failed
running hphp took 0'02" (2211429 us) wall time

[ssandler]

Oh I guess we want to bisect to when it was fixed 🤦‍♂️ . Let me do that too.

[fredemmott]

Time-saving shortcut: clone it outside the container, and use -w $(pwd) -v $(pwd):$(pwd) to mount your current directory in the container, and set it as the working directory inside the container

[ssandler]

January 22nd, segfaults

$ docker run --tty --interactive hhvm/hhvm:2019.01.22 /bin/bash -l
Unable to find image 'hhvm/hhvm:2019.01.22' locally
2019.01.22: Pulling from hhvm/hhvm
b849b56b69e7: Pull complete 
42986ef25bcd: Pull complete 
d927c1b717ec: Pull complete 
15b86ea20233: Pull complete 
5bed21384533: Pull complete 
Digest: sha256:39063f466519a7ef2bf40ca38e722a774e71cdc4697de7e21e77d6251454cf79
Status: Downloaded newer image for hhvm/hhvm:2019.01.22
root@13ee861a9d1b:/# cd /tmp && git clone https://github.com/hhvm/difflib.git && hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /tmp/difflib
Cloning into 'difflib'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 179 (delta 13), reused 23 (delta 10), pack-reused 144
Receiving objects: 100% (179/179), 60.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (72/72), done.
Checking connectivity... done.
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (10 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (9 us) wall time
analyzeProgram took 0'00" (227 us) wall time
parsing inputs took 0'00" (52977 us) wall time
analyze final...
analyze final took 0'00" (10 us) wall time
creating binary HHBC files...
running HHBBC...

---------------------------------optimize_func----------------------------------
Optimizing:Facebook\DiffLib\StringDiff::getUnifiedDiff
Core dumped: Segmentation fault
Stack trace in /tmp/stacktrace.27.log
hphp failed
running hphp took 0'02" (2234535 us) wall time
root@13ee861a9d1b:/tmp# logout

January 23rd, no segfault

$ docker run --tty --interactive hhvm/hhvm:2018.01.23 /bin/bash -l
Unable to find image 'hhvm/hhvm:2018.01.23' locally
2018.01.23: Pulling from hhvm/hhvm
8f7c85c2269a: Already exists 
9e72e494a6dd: Already exists 
3009ec50c887: Already exists 
9d5ffccbec91: Already exists 
e872a2642ce1: Already exists 
50d6563cecfe: Pull complete 
Digest: sha256:44adb9cd52b7b32b7a0e52901c4b2c9215744b392df757079be4b40660e815cc
Status: Downloaded newer image for hhvm/hhvm:2018.01.23
root@51cef38781d9:/# cd /tmp && git clone https://github.com/hhvm/difflib.git && hhvm --hphp -o /tmp/raresult -t hhbc --input-dir /tmp/difflib
Cloning into 'difflib'...
remote: Enumerating objects: 35, done.
remote: Counting objects: 100% (35/35), done.
remote: Compressing objects: 100% (25/25), done.
remote: Total 179 (delta 13), reused 23 (delta 10), pack-reused 144
Receiving objects: 100% (179/179), 60.24 KiB | 0 bytes/s, done.
Resolving deltas: 100% (72/72), done.
Checking connectivity... done.
running hphp...
parsing inputs...
analyzeProgram...
analyze all...
analyze all took 0'00" (12466 us) wall time
processImportedLambdas...
processImportedLambdas took 0'00" (6 us) wall time
analyzeProgram took 0'00" (12592 us) wall time
parsing inputs took 0'00" (22947 us) wall time
analyze final...
analyze final took 0'00" (8692 us) wall time
creating binary HHBC files...
running HHBBC...
committing units to repo...
running HHBBC took 0'00" (479751 us) wall time
committing units to repo took 0'00" (110179 us) wall time
creating binary HHBC files took 0'00" (586882 us) wall time
all files saved in /tmp/raresult ...
running hphp took 0'01" (1098334 us) wall time
root@51cef38781d9:/tmp# logout

[ssandler]

Time-saving shortcut: clone it outside the container, and use -w $(pwd) -v $(pwd):$(pwd) to mount your current directory in the container, and set it as the working directory inside the container

Thank you, I don't normally use docker :-)

[fredemmott]

We really should start pushing git tags for the nightlies :/ anyway, next step is much slower, and bisect commits, probably jan 21st-24th :(

[fredemmott]

Bisecting this is weird, and source-wise doesnt' line up with those dates.

Have a bisectable window: crashes (good): 244e6cb6e44ff91fb564d830e89d5a22739eeab2
works (bad): b3fe395824c46bd95df1619695defa753966b30c

[fredemmott]

Bisecting still in progress.

$ git bisect log
# works: [b3fe395824c46bd95df1619695defa753966b30c] Emit parse error when reify keyword is used outside of declaration position
# crash: [244e6cb6e44ff91fb564d830e89d5a22739eeab2] New inference: more tests
git bisect start '--term-old=crash' '--term-new=works' 'b3fe395824c46bd95df1619695defa753966b30c' '244e6cb6e44ff91fb564d830e89d5a22739eeab2'
# works: [6f9531fabd7135da970c9e1d79037096720cedad] Gate type param name conflict error behind experimental flag
git bisect works 6f9531fabd7135da970c9e1d79037096720cedad
# crash: [e01593d65cccc1214b34c2c501327f92eb4fa4c7] Remove func_num_args from Reflection
git bisect crash e01593d65cccc1214b34c2c501327f92eb4fa4c7

[fredemmott]

Was not actually fixed on the 23rd: test case above has a typo of 2018 instead of 2019.

I have good news and bad news:

Bad news: it's not cherry-pickable - not just "not a clean cherry-pick", it will need a different approach, because the fix is a big BC break: 4128c2aef3658721261c48f19d1d28a220e43c89

Good news:

• if you're not using destructors, this can be fixed by -v AllowObjectDestructors=false
• both this and the previous issue are dead-code-elimination related, and also tied to destructors. Hopefully this is finally resolved for future versions

@aishraj, @ssandler is disabling destructor support workable for you?

[fredemmott]

Disabling object destructors lets me build a repo for user-documentation and all recursive dependencies with 3.30; hopefully that's the broad fix for these issues.

[ssandler]

That should work for us, yes. Thanks for the investigation here, and sorry for the 2018/2019 typo 🤦‍♂️

[fredemmott]

Closing as "won't fix" as there isn't a "probably not worth time fixing as it's fixed in master and there's a solid workaround for known existing users" label - happy to re-open if something changes to affect "not worth time fixing" :)

[aishraj]

Thanks Fred :)