Track down an elusive reference leak

The pattern seems to be that we invalidate an IC (deregestering the decrefinfo),
but there is a stack frame in that IC and furthermore that stack frame will
get unwound via an exception.

The fix I did here is to not deregister the decrefinfo if num_inside>0.

src/asm_writing/icinfo.cpp

@@ -75,8 +75,10 @@ void ICInvalidator::invalidateAll() {
 
 void ICSlotInfo::clear() {
     ic->clear(this);
-    decref_infos.clear();
     used = false;
+
+    if (num_inside == 0)
+        decref_infos.clear();
 }
 
 std::unique_ptr<ICSlotRewrite> ICSlotRewrite::create(ICInfo* ic, const char* debug_name) {
@@ -133,6 +135,9 @@ void ICSlotRewrite::commit(CommitHook* hook, std::vector<void*> gc_references,
         return;
     }
 
+    // I think this can happen if another thread enters the IC?
+    RELEASE_ASSERT(ic_entry->num_inside == 1, "picked IC slot is somehow used again");
+
     auto ic = getICInfo();
     uint8_t* slot_start = getSlotStart();
     uint8_t* continue_point = (uint8_t*)ic->continue_addr;

test/tests/decrefinfo_invalidation.py

+# Regression test:
+# If we need to invalidate an IC, and there is a stack frame in that IC,
+# we have to be careful to not clear the DecrefInfo of that IC in case
+# an exception traverses that stack frame.
+
+# In this example, g() has an IC to f() that will get invalidated when
+# f() tiers up.
+
+def h():
+    def f(n):
+        if n > 1000:
+            raise Exception()
+    def g(n):
+        f(n)
+
+    for i in xrange(10000):
+        try:
+            g(i)
+        except:
+            pass
+h()