Crash and Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.

[Clingto]

My slice command is:

./llvm-slicer -c malloc test_slice.bc

And the crash info:

start ...
SC: Matched 'malloc()' to: 
    %call79 = call noalias i8* @malloc(i64 80) #7, !dbg !413
    %call410 = call noalias i8* @malloc(i64 48) #6, !dbg !897
    %call418 = call noalias i8* @malloc(i64 48) #6, !dbg !914
    %call44 = call noalias i8* @malloc(i64 %mul43) #6, !dbg !440
    %call50 = call noalias i8* @malloc(i64 %mul49) #6, !dbg !452
    %call93 = call noalias i8* @malloc(i64 %mul92) #6, !dbg !524
    %call156 = call noalias i8* @malloc(i64 %mul155) #6, !dbg !642
While deleting: %struct.ngiflib_img** %i.addr
Use still stuck around after Def is destroyed:  %14 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !382
Use still stuck around after Def is destroyed:  %11 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !379
Use still stuck around after Def is destroyed:  %8 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !374
Use still stuck around after Def is destroyed:  %6 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !372
Use still stuck around after Def is destroyed:  %4 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !368
Use still stuck around after Def is destroyed:  %2 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !365
Use still stuck around after Def is destroyed:  %0 = load %struct.ngiflib_img*, %struct.ngiflib_img** %i.addr, align 8, !dbg !361
llvm-slicer: /home/aota05/MC_xxFuzz/llvm/llvm/lib/IR/Value.cpp:88: llvm::Value::~Value(): Assertion `use_empty() && "Uses remain when a value is destroyed!"' failed.
#0 0x00007ffff79e649a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x28049a)
#1 0x00007ffff79e423e llvm::sys::RunSignalHandlers() (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x27e23e)
#2 0x00007ffff79e43b2 SignalHandler(int) (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x27e3b2)
#3 0x00007ffff615b4c0 (/lib/x86_64-linux-gnu/libc.so.6+0x354c0)
#4 0x00007ffff615b438 gsignal /build/glibc-S7Ft5T/glibc-2.23/signal/../sysdeps/unix/sysv/linux/raise.c:54:0
#5 0x00007ffff615d03a abort /build/glibc-S7Ft5T/glibc-2.23/stdlib/abort.c:91:0
#6 0x00007ffff6153be7 __assert_fail_base /build/glibc-S7Ft5T/glibc-2.23/assert/assert.c:92:0
#7 0x00007ffff6153c92 (/lib/x86_64-linux-gnu/libc.so.6+0x2dc92)
#8 0x00007ffff7934ccb (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x1ceccb)
#9 0x00007ffff7934d20 llvm::Value::deleteValue() (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x1ced20)
#10 0x00007ffff786510c llvm::BasicBlock::~BasicBlock() (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0xff10c)
#11 0x00007ffff78669c5 llvm::BasicBlock::eraseFromParent() (/home/aota05/yyp/slice_fuzz/dg/build/tools/libdgllvmslicer.so+0x1009c5)
#12 0x00007ffff782d9ec dg::llvmdg::cutoffDivergingBranches(llvm::Module&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<llvm::Value const*, std::allocator<llvm::Value const*> > const&) /home/aota05/yyp/slice_fuzz/dg/tools/llvm-slicer-preprocess.cpp:171:0
#13 0x000000000044ea1d main /home/aota05/yyp/slice_fuzz/dg/tools/llvm-slicer.cpp:234:0
#14 0x00007ffff6146840 __libc_start_main /build/glibc-S7Ft5T/glibc-2.23/csu/../csu/libc-start.c:325:0
#15 0x000000000044fc69 _start (/home/aota05/yyp/slice_fuzz/dg/build/tools/llvm-slicer+0x44fc69)
../../slice_ngiflib_bin.sh: line 19: 31935 Aborted                 $SLICE_PATH/llvm-slicer -c malloc $PRJ_PATH/ngiflib/SRC_bin/test_slice.bc

Could you give me some advice? Thanks.

[mchalupa]

Seems like a bug in -cutoff-diverging option. You can workaround it for now with -cutoff-diverging=0. Do you have some small test-case that would allow to reproduce this bug?

[Clingto]

Hi, I tested the “-cutoff-diverging=0” option, and it seems not to work.

I put my data of proof-of-concept to reproduce this bug in the public git repo.

And the link is: https://github.com/Clingto/POC/tree/master/POCs-DG/ngiflib

And it contains: 1、The source code of program is in the file directory "code"; 2、I built the ngiflib program with bash script ("build_ngiflib_bin.sh"); 3、I sliced it with dg/llvm-slicer tool with bash script ("slice_ngiflib_bin.sh") 4、My original ".bc" file is in the file directory "SRC_bin/test_slice.bc"; 5、Environment: clang version 6.0.0 mchalupa/dg version is git ce1b0724f3

[Clingto]

Seems like a bug in -cutoff-diverging option. You can workaround it for now with -cutoff-diverging=0. Do you have some small test-case that would allow to reproduce this bug?

Hi, I tested the “-cutoff-diverging=0” option, and it seems not to work.

I put my data of proof-of-concept to reproduce this bug in the public git repo.

And the link is: https://github.com/Clingto/POC/tree/master/POCs-DG/ngiflib

And it contains: 1、The source code of program is in the file directory "code"; 2、I built the ngiflib program with bash script ("build_ngiflib_bin.sh"); 3、I sliced it with dg/llvm-slicer tool with bash script ("slice_ngiflib_bin.sh") 4、My original ".bc" file is in the file directory "SRC_bin/test_slice.bc"; 5、Environment: clang version 6.0.0 mchalupa/dg version is git ce1b0724f3

[Clingto]

Seems like a bug in -cutoff-diverging option. You can workaround it for now with -cutoff-diverging=0. Do you have some small test-case that would allow to reproduce this bug?

Looking forward to your reply. Thanks.