Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file include/llvm/ADT/ScopedHashTable.h, line 245.

[pkubaj]

Bugzilla Link	45206
Resolution	DUPLICATE
Resolved on	Mar 19, 2020 04:52
Version	10.0
OS	FreeBSD
Blocks	#43900
Attachments	bug reproduction files
CC	@efriedma-quic,@zmodem,@rotateright

Extended Description

I use FreeBSD head on powerpc64 with LLVM 10 rc3.

Compiling math/gsl port fails with:
/bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c -o cgbmv.lo cgbmv.c
libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o
Assertion failed: (HT.TopLevelMap[ThisEntry->getKey()] == ThisEntry && "Scope imbalance!"), function ~ScopedHashTableScope, file /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/ScopedHashTable.h, line 245.
Stack dump:
0. Program arguments: cc -DHAVE_CONFIG_H -I. -I.. -I.. -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -MT cgbmv.lo -MD -MP -MF .deps/cgbmv.Tpo -c cgbmv.c -fPIC -DPIC -o .libs/cgbmv.o

1.  <eof> parser at end of file
   

2.  Code generation
   

3.  Running pass 'Function Pass Manager' on module 'cgbmv.c'.
   

4.  Running pass 'Early CSE' on function '@cblas_cgbmv'
   

#​0 0x0000000013bac208 PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#​1 0x0000000013ba98d0 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:67:5
#​2 0x0000000013baf278 HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:75:7
#​3 0x0000000013baf4ec CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51
#​4 0x0000000815732748 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:303:3
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 10.0.0 (git@github.com:llvm/llvm-project.git llvmorg-10.0.0-rc3-1-gc290cb61fdc)
Target: powerpc64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

Files for reproducing this issue are attached.

[efriedma-quic]

Does this reproduce on master? Maybe a duplicate of bug #40428

[zmodem]

Does this reproduce on master? Maybe a duplicate of bug #40428

That's it. It doesn't reproduce on master, because it was fixed by b8ebc11.

Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0.

Can someone comment on the severity of this? I wasn't planning on doing another release candidate, but we could if we have to of course.

*** This bug has been marked as a duplicate of bug #40428 ***

[pkubaj]

Does this reproduce on master? Maybe a duplicate of bug #40428

That's it. It doesn't reproduce on master, because it was fixed by
b8ebc11.

Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0.

Can someone comment on the severity of this? I wasn't planning on doing
another release candidate, but we could if we have to of course.

*** This bug has been marked as a duplicate of bug #40428 ***

On FreeBSD we can just backport this patch, I already sent a request to dim@ (although it would be of course better to have it upstreamed for the release). I'm not in a position to talk about other systems.

[rotateright]

Does this reproduce on master? Maybe a duplicate of bug #40428

That's it. It doesn't reproduce on master, because it was fixed by
b8ebc11.

Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0.

Can someone comment on the severity of this? I wasn't planning on doing
another release candidate, but we could if we have to of course.

*** This bug has been marked as a duplicate of bug #40428 ***

The bug will manifest as an assert as shown here, but I don't have an estimate for how often that happens. I also don't know what happens with a no-asserts build.

A quick check of an 'opt 9.0' here:
https://godbolt.org/z/_rCqfc

...does not show a crash, so either this bug is a regression from 9.0 or that binary was built without asserts?

The fix has been in trunk long enough, that I'd call the patch low risk. If it doesn't make it into 10.0.0, it should definitely be a candidate for 10.0.1.

[pkubaj]

Does this reproduce on master? Maybe a duplicate of bug #40428

That's it. It doesn't reproduce on master, because it was fixed by
b8ebc11.

Sadly I hadn't seen that bug/fix, and now it might be too late for 10.0.0.

Can someone comment on the severity of this? I wasn't planning on doing
another release candidate, but we could if we have to of course.

*** This bug has been marked as a duplicate of bug #40428 ***

The bug will manifest as an assert as shown here, but I don't have an
estimate for how often that happens. I also don't know what happens with a
no-asserts build.

A quick check of an 'opt 9.0' here:
https://godbolt.org/z/_rCqfc

...does not show a crash, so either this bug is a regression from 9.0 or
that binary was built without asserts?

The fix has been in trunk long enough, that I'd call the patch low risk. If
it doesn't make it into 10.0.0, it should definitely be a candidate for
10.0.1.

This is definitely a regression from 9.0.1 - math/gsl port built with 9.0.1 just fine.

[zmodem]

Okay, this seems bad enough that it warrants another release candidate.

I've cherry-picked the test update as cfa7924 and the fix as 623461b. Then I had to re-generate the test in 5401d39.

This will be in rc5.

It's unfortunate that we only found out about this so late in the release process, even though the fix landed more than a month ago. But these things happen.

[rotateright]

It's unfortunate that we only found out about this so late in the release
process, even though the fix landed more than a month ago. But these things
happen.

Sorry about that. I'll try to be more aware of the release cycle going forward. Thank you for all of the work in getting the release out!