GC error during Pkg test

[JeffBezanson]

There have been some crashes in the GC during 32-bit linux various builds recently.

Examples here:
https://travis-ci.org/JuliaLang/julia/jobs/210492169
https://travis-ci.org/JuliaLang/julia/jobs/210815302

Stack trace backed up here:
https://gist.github.com/JeffBezanson/c97263bc651de52f886a9cb0be1711eb

[ararslan]

Linux only or have you noticed it with 32-bit Windows as well?

[pabloferz]

Here's another on 64-bit Windows

https://ci.appveyor.com/project/JuliaLang/julia/build/1.0.12094

[StefanKarpinski]

Any possibility that some of @Keno's recent tweaks were slightly incorrect?

[yuyichao]

Caught in rr and it seems to be a codegen bug caused by #20593

With

@noinline function f(i)
    i % 2 == 0 ? 1 : ""
end
g() = (f(1), f(2))

@code_llvm g() is

define i8** @julia_g_68317() #0 !dbg !5 {
top:
  %0 = alloca [8 x i8], align 8
  %1 = alloca [8 x i8], align 8
  %ptls_i8 = call i8* asm "movq %fs:0, $0;\0Aaddq $$-10896, $0", "=r,~{dirflag},~{fpsr},~{flags}"() #3
  %ptls = bitcast i8* %ptls_i8 to i8****
  %2 = alloca [4 x i8**], align 8
  %.sub = getelementptr inbounds [4 x i8**], [4 x i8**]* %2, i64 0, i64 0
  %3 = getelementptr [4 x i8**], [4 x i8**]* %2, i64 0, i64 2
  %4 = bitcast i8*** %3 to i8*
  call void @llvm.memset.p0i8.i32(i8* %4, i8 0, i32 16, i32 8, i1 false)
  %5 = bitcast [4 x i8**]* %2 to i64*
  store i64 4, i64* %5, align 8
  %6 = getelementptr [4 x i8**], [4 x i8**]* %2, i64 0, i64 1
  %7 = bitcast i8* %ptls_i8 to i64*
  %8 = load i64, i64* %7, align 8
  %9 = bitcast i8*** %6 to i64*
  store i64 %8, i64* %9, align 8
  store i8*** %.sub, i8**** %ptls, align 8
  %10 = call { i8**, i8 } @julia_f_68311([8 x i8]* noalias nocapture nonnull %0, i64 1)
  %11 = extractvalue { i8**, i8 } %10, 1
  %12 = extractvalue { i8**, i8 } %10, 0
  %13 = call { i8**, i8 } @julia_f_68311([8 x i8]* noalias nocapture nonnull %1, i64 2)
  %cond = icmp eq i8 %11, 1
  br i1 %cond, label %box_union, label %post_box_union

post_box_union:                                   ; preds = %top, %box_union
  %14 = phi i8** [ %19, %box_union ], [ %12, %top ]
  %15 = extractvalue { i8**, i8 } %13, 1
  %16 = extractvalue { i8**, i8 } %13, 0
  store i8** %14, i8*** %3, align 8
  %cond4 = icmp eq i8 %15, 1
  br i1 %cond4, label %box_union3, label %post_box_union2

box_union:                                        ; preds = %top
  %17 = bitcast i8** %12 to i64*
  %18 = load i64, i64* %17, align 8
  %19 = call i8** @jl_box_int64(i64 signext %18)
  br label %post_box_union

post_box_union2:                                  ; preds = %post_box_union, %box_union3
  %20 = phi i8** [ %26, %box_union3 ], [ %16, %post_box_union ]
  %21 = getelementptr [4 x i8**], [4 x i8**]* %2, i64 0, i64 3
  store i8** %20, i8*** %21, align 8
  %22 = call i8** @jl_f_tuple(i8** null, i8*** %3, i32 2)
  %23 = load i64, i64* %9, align 8
  store i64 %23, i64* %7, align 8
  ret i8** %22

box_union3:                                       ; preds = %post_box_union
  %24 = bitcast i8** %16 to i64*
  %25 = load i64, i64* %24, align 8
  %26 = call i8** @jl_box_int64(i64 signext %25)
  br label %post_box_union2
}

In particular

  %10 = call { i8**, i8 } @julia_f_68311([8 x i8]* noalias nocapture nonnull %0, i64 1)
  %11 = extractvalue { i8**, i8 } %10, 1
  %12 = extractvalue { i8**, i8 } %10, 0
  %13 = call { i8**, i8 } @julia_f_68311([8 x i8]* noalias nocapture nonnull %1, i64 2)

Does not store the heap allocated result from the first function anywhere before calling the second function.

@vtjnash

[yuyichao]

And O0 IR just for reference.

[vtjnash]

Ah, good catch. Yes, the new code path for unions doesn't get to use the mostly automatic handling of mark_julia_type, and needs to manually generate the root for all union return values.