llvm dev - Feb 2020 - Interpreter crash due to an "Unknown constant pointer type!"

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/20200103/828f8cd0/attachment.html>

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/20200103/a63f9b25/attachment.html>

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>

>
> 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/321db11e/attachment-0001.html>