[llvm-dev] Interpreter crash due to an "Unknown constant pointer type!"

Alberto Barbaro via llvm-dev llvm-dev at lists.llvm.org
Sat Feb 1 01:32:25 PST 2020


Hi all,
just a gentle reminder :) Is there any update on this please?

Happy to help in any way I can

Alberto

Il giorno ven 3 gen 2020 alle ore 23:04 David Blaikie <dblaikie at gmail.com>
ha scritto:

> Hey Lang - does any of this look familiar to you?
>
> On Fri, Jan 3, 2020 at 7:04 AM Alberto Barbaro <barbaro.alberto at gmail.com>
> wrote:
>
>> David,
>> sorry for this email but I noticed I made a mistake in the previous one.
>> So I managed to compile llvm Debug with asserts release. I have used the
>> following commands:
>>
>> cmake -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_RTTI=ON
>> -DLLVM_ENABLE_FFI=ON -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_ASSERTIONS=ON ..
>> cmake --build . -- -j8 && sudo cmake --build . --target install
>>
>> Once lli was installed it was enough to use the .bc
>>
>> /usr/local/bin/lli --debug --force-interpreter pngpixel_crash.bc 0 0
>> mini.png
>> ...
>> png_ptr->width: 1
>> max_pixel_depth: 24
>> row_bytes: 28
>> ...
>> About to interpret:   store <2 x %struct.code*> <%struct.code*
>> getelementptr inbounds ([512 x %struct.code], [512 x %struct.code]*
>> @fixedtables.lenfix.681, i64 0, i64 0), %struct.code* getelementptr
>> inbounds ([32 x %struct.code], [32 x %struct.code]*
>> @fixedtables.distfix.682, i64 0, i64 0)>, <2 x %struct.code*>* %96, align
>> 8, !tbaa !50
>> Unknown constant pointer type!
>> UNREACHABLE executed at
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/ExecutionEngine.cpp:1008!
>> Stack dump:
>> 0. Program arguments: /usr/local/bin/lli --force-interpreter
>> pngpixel_crash.bc 0 0 mini.png
>>  #0 0x0000564bad642af9 llvm::sys::PrintStackTrace(llvm::raw_ostream&)
>> /home/al/llvm-9.0.0.src/lib/Support/Unix/Signals.inc:533:0
>>  #1 0x0000564bad642b8c PrintStackTraceSignalHandler(void*)
>> /home/al/llvm-9.0.0.src/lib/Support/Unix/Signals.inc:594:0
>>  #2 0x0000564bad640a66 llvm::sys::RunSignalHandlers()
>> /home/al/llvm-9.0.0.src/lib/Support/Signals.cpp:68:0
>>  #3 0x0000564bad6424b0 SignalHandler(int)
>> /home/al/llvm-9.0.0.src/lib/Support/Unix/Signals.inc:385:0
>>  #4 0x00007f697df61890 __restore_rt
>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
>>  #5 0x00007f697ca0ae97 raise
>> /build/glibc-OTsEL5/glibc-2.27/signal/../sysdeps/unix/sysv/linux/raise.c:51:0
>>  #6 0x00007f697ca0c801 abort
>> /build/glibc-OTsEL5/glibc-2.27/stdlib/abort.c:81:0
>>  #7 0x0000564bad5ce768 bindingsErrorHandler(void*,
>> std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> > const&, bool)
>> /home/al/llvm-9.0.0.src/lib/Support/ErrorHandling.cpp:218:0
>>  #8 0x0000564bacfc2e5a
>> llvm::ExecutionEngine::getConstantValue(llvm::Constant const*)
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/ExecutionEngine.cpp:1013:0
>>  #9 0x0000564bacfeb873 llvm::Interpreter::getOperandValue(llvm::Value*,
>> llvm::ExecutionContext&)
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/Interpreter/Execution.cpp:2108:0
>> #10 0x0000564bacfe548a
>> llvm::Interpreter::visitStoreInst(llvm::StoreInst&)
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/Interpreter/Execution.cpp:1105:0
>> #11 0x0000564bacfee32f llvm::InstVisitor<llvm::Interpreter,
>> void>::visitStore(llvm::StoreInst&)
>> /home/al/llvm-9.0.0.src/include/llvm/IR/Instruction.def:173:0
>> #12 0x0000564bacfed18d llvm::InstVisitor<llvm::Interpreter,
>> void>::visit(llvm::Instruction&)
>> /home/al/llvm-9.0.0.src/include/llvm/IR/Instruction.def:173:0
>> #13 0x0000564bacfebd7b llvm::Interpreter::run()
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/Interpreter/Execution.cpp:2161:0
>> #14 0x0000564bacfd6bdc llvm::Interpreter::runFunction(llvm::Function*,
>> llvm::ArrayRef<llvm::GenericValue>)
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/Interpreter/Interpreter.cpp:101:0
>> #15 0x0000564bacfbfb94
>> llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
>> std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,
>> std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char,
>> std::char_traits<char>, std::allocator<char> > > > const&, char const*
>> const*)
>> /home/al/llvm-9.0.0.src/lib/ExecutionEngine/ExecutionEngine.cpp:470:0
>> #16 0x0000564bac794cc4 main
>> /home/al/llvm-9.0.0.src/tools/lli/lli.cpp:614:0
>> #17 0x00007f697c9edb97 __libc_start_main
>> /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:344:0
>> #18 0x0000564bac791a9a _start (/usr/local/bin/lli+0x110aa9a)
>> [1]    12828 abort (core dumped)  /usr/local/bin/lli --force-interpreter
>> pngpixel_crash.bc 0 0 mini.png
>>
>> So I'm certaint that the crash happend
>> in ExecutionEngine::getConstantValue.
>>
>> In addition, I have noticed that ElemTy->getTypeID() is 15 ( pointer type
>> of type struct.code ) but the switch branch ( Line 917 ) in not able to
>> deal with it so the llvm_unrecheable instruction is reached.
>>
>> So I can conclude that the problem is that the switch branch is not able
>> to deal with pointers.. Any suggestion on how to fix it please?
>>
>> Do it help to narrow down the problem?
>>
>> Thanks
>>
>>
>> Il giorno ven 3 gen 2020 alle ore 11:28 Alberto Barbaro <
>> barbaro.alberto at gmail.com> ha scritto:
>>
>>> David,
>>> Using llvm 9 the crash is not present anymore. I think it was just time
>>> for me to update my code...
>>>
>>> Thanks for your help
>>>
>>> Alberto
>>>
>>> On Tue, Dec 24, 2019, 21:16 Alberto Barbaro <barbaro.alberto at gmail.com>
>>> wrote:
>>>
>>>> Hi David,
>>>> In pretty sure that the crash is due to the instruction I have shared
>>>> in my first email. In order to run pngpixel you just need libpng and zlib..
>>>> honest I thought that the .bc had Al the necessary. I'm happy to help you
>>>> to reproduce it. As a curiosity, why do you think you cannot reproduce it?
>>>>
>>>> Unfortunately I won't be able to modify the interpreter soon.. anyway,
>>>> I'll try to dump s much info as possible.
>>>>
>>>> Thanks
>>>> Alberto
>>>>
>>>>
>>>> On Tue, Dec 24, 2019, 22:09 David Blaikie <dblaikie at gmail.com> wrote:
>>>>
>>>>> I can't reproduce it (just because of other local differences that
>>>>> lead to failures before it reaches this point, not because it passes for me
>>>>> or anything)
>>>>>
>>>>> I'd suggest you hop in with a debugger and/or modify the interpreter
>>>>> to print more information at that unreachable - to see what sort of type
>>>>> you do have & maybe then it'll be more clear what should be done with that
>>>>> type, or why it's a weird type, etc.
>>>>>
>>>>> On Thu, Dec 19, 2019 at 11:32 AM Alberto Barbaro <
>>>>> barbaro.alberto at gmail.com> wrote:
>>>>>
>>>>>> Hi David,
>>>>>> Thanks for the suggestions. I can definitely provide the example bc
>>>>>> file and image ( please see the attachments ). For the debug + asserts I
>>>>>> need a bit of more time.
>>>>>>
>>>>>> Anyway the full output of lli is:
>>>>>>
>>>>>> lli --force-interpreter examples/pngpixel_crash.bc 0 0
>>>>>> examples/mini.png
>>>>>> png_ptr->width: 1
>>>>>> max_pixel_depth: 24
>>>>>> row_bytes: 28
>>>>>> Unknown constant pointer type!
>>>>>> UNREACHABLE executed at
>>>>>> /home/al/Desktop/llvm-6.0.1.src/lib/ExecutionEngine/ExecutionEngine.cpp:1007!
>>>>>> LLVMSymbolizer: error reading file: No such file or directory
>>>>>> #0 0x0000000001765ee9 (lli+0x1765ee9)
>>>>>> #1 0x0000000001766099 (lli+0x1766099)
>>>>>> #2 0x0000000001764643 (lli+0x1764643)
>>>>>> #3 0x0000000001766424 (lli+0x1766424)
>>>>>> #4 0x00007f5dc5fc7890 __restore_rt
>>>>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
>>>>>> #5 0x00007f5dc4a85e97 gsignal
>>>>>> (/lib/x86_64-linux-gnu/libc.so.6+0x3ee97)
>>>>>> #6 0x00007f5dc4a87801 abort (/lib/x86_64-linux-gnu/libc.so.6+0x40801)
>>>>>> #7 0x00000000016d7150 (lli+0x16d7150)
>>>>>> #8 0x0000000001139543 (lli+0x1139543)
>>>>>> #9 0x00000000011500b8 (lli+0x11500b8)
>>>>>> #10 0x000000000115c25d (lli+0x115c25d)
>>>>>> #11 0x0000000001167d32 (lli+0x1167d32)
>>>>>> #12 0x000000000116430d (lli+0x116430d)
>>>>>> #13 0x0000000001163580 (lli+0x1163580)
>>>>>> #14 0x000000000114e197 (lli+0x114e197)
>>>>>> #15 0x0000000001135ba0 (lli+0x1135ba0)
>>>>>> #16 0x00000000008c729d (lli+0x8c729d)
>>>>>> #17 0x00007f5dc4a68b97 __libc_start_main
>>>>>> (/lib/x86_64-linux-gnu/libc.so.6+0x21b97)
>>>>>> #18 0x00000000008c4f1a (lli+0x8c4f1a)
>>>>>> Stack dump:
>>>>>> 0. Program arguments: lli --force-interpreter
>>>>>> examples/pngpixel_crash.bc 0 0 examples/mini.png
>>>>>> [1]    4344 abort (core dumped)  lli --force-interpreter
>>>>>> examples/pngpixel_crash.bc 0 0 examples/mini.png
>>>>>>
>>>>>> Please let me know if you can reproduce it!!
>>>>>>
>>>>>> Thanks
>>>>>> Alberto
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 19, 2019, 19:10 David Blaikie <dblaikie at gmail.com> wrote:
>>>>>>
>>>>>>> Probably need a debug (& probably +Asserts) build to see more about
>>>>>>> where it's failing & that might help you fix it - if you want other folks
>>>>>>> to be able to help debug the issue, providing the full reproduction steps
>>>>>>> (the entire input files, what commands were run, etc) - though, preferably,
>>>>>>> minimized (simplify the inputs/commands, etc, while still producing the
>>>>>>> failure)
>>>>>>>
>>>>>>> On Thu, Dec 19, 2019 at 11:06 AM Alberto Barbaro via llvm-dev <
>>>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> as usual I'm playing with the Interpreter and unfortunately I hit a
>>>>>>>> crash. I have narrowed down the problem an the crash happens inside the
>>>>>>>> inflate function which is part of zlib and specifically at the instruction:
>>>>>>>>
>>>>>>>> store <2 x %struct.code*> <%struct.code* getelementptr inbounds
>>>>>>>> ([512 x %struct.code], [512 x %struct.code]* @fixedtables.lenfix.681, i64
>>>>>>>> 0, i64 0), %struct.code* getelementptr inbounds ([32 x %struct.code], [32 x
>>>>>>>> %struct.code]* @fixedtables.distfix.682, i64 0, i64 0)>, <2 x
>>>>>>>> %struct.code*>* %96, align 8, !tbaa !46
>>>>>>>>
>>>>>>>> The output from lli is:
>>>>>>>>
>>>>>>>> Unknown constant pointer type!
>>>>>>>> UNREACHABLE executed at
>>>>>>>> /home/al/Desktop/llvm-6.0.1.src/lib/ExecutionEngine/ExecutionEngine.cpp:1007!
>>>>>>>> LLVMSymbolizer: error reading file: No such file or directory
>>>>>>>> #0 0x0000000001765ee9 (lli+0x1765ee9)
>>>>>>>> #1 0x0000000001766099 (lli+0x1766099)
>>>>>>>> #2 0x0000000001764643 (lli+0x1764643)
>>>>>>>> #3 0x0000000001766424 (lli+0x1766424)
>>>>>>>> #4 0x00007faade157890 __restore_rt
>>>>>>>> (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
>>>>>>>> #5 0x00007faadcc15e97 gsignal
>>>>>>>> (/lib/x86_64-linux-gnu/libc.so.6+0x3ee97)
>>>>>>>> #6 0x00007faadcc17801 abort
>>>>>>>> (/lib/x86_64-linux-gnu/libc.so.6+0x40801)
>>>>>>>> #7 0x00000000016d7150 (lli+0x16d7150)
>>>>>>>> #8 0x0000000001139543 (lli+0x1139543)
>>>>>>>> #9 0x00000000011500b8 (lli+0x11500b8)
>>>>>>>> #10 0x000000000115c25d (lli+0x115c25d)
>>>>>>>> #11 0x0000000001167d32 (lli+0x1167d32)
>>>>>>>> #12 0x000000000116430d (lli+0x116430d)
>>>>>>>> #13 0x0000000001163580 (lli+0x1163580)
>>>>>>>> #14 0x000000000114e197 (lli+0x114e197)
>>>>>>>> #15 0x0000000001135ba0 (lli+0x1135ba0)
>>>>>>>> #16 0x00000000008c729d (lli+0x8c729d)
>>>>>>>> #17 0x00007faadcbf8b97 __libc_start_main
>>>>>>>> (/lib/x86_64-linux-gnu/libc.so.6+0x21b97)
>>>>>>>> #18 0x00000000008c4f1a (lli+0x8c4f1a)
>>>>>>>>
>>>>>>>> Is there anyone that can help me to understand how to fix it even a
>>>>>>>> simple workaround for the moment would be enough!
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Alberto
>>>>>>>> _______________________________________________
>>>>>>>> LLVM Developers mailing list
>>>>>>>> llvm-dev at lists.llvm.org
>>>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200201/7b8d8282/attachment.html>


More information about the llvm-dev mailing list