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

Mon Feb 10 13:55:46 PST 2020

Hi Lang,
I'm using the interpreter because my goal is to use it as a visitor and
follow the execution instruction per instruction.

Is it the same possible with a JIT class?

Thanks

On Mon, Feb 10, 2020, 21:31 Lang Hames <lhames at gmail.com> wrote:

> Hey Lang - does any of this look familiar to you?
>
>
> I'm afraid not: I know nothing about the interpreter. As far as I'm aware
> it's essentially abandonware.
>
> Alberto: The usual recommendation in these circumstances is to use a JIT
> class instead of the interpreter. You're using -force-interpreter though,
> so I assume you really want to use the interpreter for your use case?
>
> -- Lang.
>
> On Fri, Jan 3, 2020 at 3:04 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> 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/20200210/aca691dd/attachment.html>