[lldb-dev] Disassembling issue
Hi everyone, I'm trying to have lldb being able to debug my architecture. It does it well after loading my elf. But then I run it, stop it in middle, try to disassemble and at that point it seems that I lost some information about my architecture. lldb tries to disassemble it for x86, which in not possible with my toolchain. Here is a log of what I am doing: (lldb) file test Current executable set to 'test' (dpu). (lldb) dis -s 0x8000 test`__bootstrap: test[0x8000] <+0>: jnzid, 0x8020 test[0x8008] <+8>: move r0, 0xff test[0x8010] <+16>: release r0, 0x0, nz, 0x8018 test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010 (lldb) r Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu) Process 21312 stopped * thread #1, name = 'DPUthread0', stop reason = Thread stopped frame #0: 0x8090 (lldb) dis -s 0x8000 error: Unable to find Disassembler plug-in for the 'x86_64' architecture. (lldb) Any ideas of what I am missing in my implementation? Thanks, -- *Romaric JODIN* UPMEM *Software Engineer* ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Disassembling issue
Hi Ted, Thank you for the answer. I'm not sure I understand you well. It seems to me that my program call "Disassembler::FindPlugin" with the "m_options.arch" set to "x86_64". But my toolchain does not contain a LLVM supporting x86_64, so it feels normal to me that it is not able to create this disassembler. What is weird is that the first time I'm executing it, it managed to do so. I also have kind of the same issue with breakpoint. It's like if I'm missing the debug information after I do the "run" command: (lldb) file test Current executable set to 'test' (dpu). (lldb) b main Breakpoint 1: where = test`main + 24 at test.c:8, address = 0x8078 (lldb) r Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu) Process 21312 stopped * thread #1, name = 'DPUthread0', stop reason = Thread finished frame #0: 0x80c0 (lldb) b main Breakpoint 2: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. When I'm doing the disassembly, I can manage to disassemble if I add the option with my architecture to the command line, but as you can see below, I also do not have the debug information that I had at the first disassembly: (lldb) file test Current executable set to 'test' (dpu). (lldb) dis -s 0x8000 test`__bootstrap: test[0x8000] <+0>: jnzid, 0x8020 test[0x8008] <+8>: move r0, 0xff test[0x8010] <+16>: release r0, 0x0, nz, 0x8018 test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010 (lldb) r Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' (dpu) Process 21312 stopped * thread #1, name = 'DPUthread0', stop reason = Thread finished frame #0: 0x80a0 (lldb) dis -s 0x8000 error: Unable to find Disassembler plug-in for the 'x86_64' architecture. (lldb) dis -s 0x8000 -A dpu 0x8000: jnzid, 0x8020 0x8008: move r0, 0xff 0x8010: release r0, 0x0, nz, 0x8018 0x8018: subr0, r0, 0x1, pl, 0x8010 Any ideas about it? Thanks, Romaric On Wed, Jun 12, 2019 at 6:55 PM Ted Woodward wrote: > The error is coming from source/Commands/CommandObjectDisassemble.cpp . > It’s not able to create the disassembler for your architecture. The call to > Disassembler::FindPlugin fails. > > My guess is something in the call to MCDisasmInstance::Create in > source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp is failing. Step > through that and make sure everything there is working. > > > > Ted > > > > *From:* lldb-dev *On Behalf Of *Romaric > Jodin via lldb-dev > *Sent:* Wednesday, June 12, 2019 8:23 AM > *To:* lldb-dev@lists.llvm.org > *Subject:* [EXT] [lldb-dev] Disassembling issue > > > > Hi everyone, > > > > I'm trying to have lldb being able to debug my architecture. It does it > well after loading my elf. But then I run it, stop it in middle, try to > disassemble and at that point it seems that I lost some information about > my architecture. lldb tries to disassemble it for x86, which in not > possible with my toolchain. > > > > Here is a log of what I am doing: > > > > (lldb) file test > > Current executable set to 'test' (dpu). > > (lldb) dis -s 0x8000 > > test`__bootstrap: > > test[0x8000] <+0>: jnzid, 0x8020 > > test[0x8008] <+8>: move r0, 0xff > > test[0x8010] <+16>: release r0, 0x0, nz, 0x8018 > > test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010 > > (lldb) r > > Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' > (dpu) > > Process 21312 stopped > > * thread #1, name = 'DPUthread0', stop reason = Thread stopped > > frame #0: 0x8090 > > (lldb) dis -s 0x8000 > > error: Unable to find Disassembler plug-in for the 'x86_64' architecture. > > (lldb) > > > > Any ideas of what I am missing in my implementation? > > Thanks, > > -- > > *Romaric JODIN* > > UPMEM > > *Software Engineer* > > > > -- *Romaric JODIN* UPMEM *Software Engineer* ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Disassembling issue
Hi Ted, Indeed, my lldb-server was returning the x86 triple. I have managed to return the good triple by "hacking" the function "GDBRemoteCommunicationServerCommon::Handle_qHostInfo" to return my "ArchSpec" instead of going through the "HostInfo::GetArchitecture()" function. I think my problem is more about how I added my architecture into lldb. I will start a new thread about it. Thank you Ted for the answers, it was very helpful. Romaric On Thu, Jun 13, 2019 at 6:38 PM Ted Woodward wrote: > Hi Romaric, > > > > The call to Disassembler::FindPlugin should have arch set to your triple. > If m_options.arch is not set on the disassembly command line, it will get > it from the target: > > > > if (!m_options.arch.IsValid()) > > m_options.arch = target->GetArchitecture(); > > > > > > That leads me to wonder if your triple is set correctly after you do the > run. What is the output from these commands, when you’re stopped?: > > > > target list > > platform status > > > > My guess is you’re connected to a remote gdb-server on a simulator for > dpu, and it’s telling lldb that the triple is x86_64.x.x. > > > > If target list says the arch is dpu before the run, and x86_64 after the > run, we should look at the RSP log. Before the run, type > > log enable -f gdb-remote packets > > > > Attach the file to your next message. > > > > Ted > > > > *From:* Romaric Jodin > *Sent:* Thursday, June 13, 2019 1:16 AM > *To:* Ted Woodward > *Cc:* LLDB > *Subject:* [EXT] Re: [lldb-dev] Disassembling issue > > > > Hi Ted, > > > > Thank you for the answer. > > I'm not sure I understand you well. It seems to me that my program call > "Disassembler::FindPlugin" with the "m_options.arch" set to "x86_64". But > my toolchain does not contain a LLVM supporting x86_64, so it feels normal > to me that it is not able to create this disassembler. What is weird is > that the first time I'm executing it, it managed to do so. > > > > I also have kind of the same issue with breakpoint. It's like if I'm > missing the debug information after I do the "run" command: > > > > (lldb) file test > > Current executable set to 'test' (dpu). > > (lldb) b main > > Breakpoint 1: where = test`main + 24 at test.c:8, address = 0x8078 > > (lldb) r > > Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' > (dpu) > > Process 21312 stopped > > * thread #1, name = 'DPUthread0', stop reason = Thread finished > > frame #0: 0x80c0 > > (lldb) b main > > Breakpoint 2: no locations (pending). > > WARNING: Unable to resolve breakpoint to any actual locations. > > > > When I'm doing the disassembly, I can manage to disassemble if I add the > option with my architecture to the command line, but as you can see below, > I also do not have the debug information that I had at the first > disassembly: > > > > (lldb) file test > > Current executable set to 'test' (dpu). > > (lldb) dis -s 0x8000 > > test`__bootstrap: > > test[0x8000] <+0>: jnzid, 0x8020 > > test[0x8008] <+8>: move r0, 0xff > > test[0x8010] <+16>: release r0, 0x0, nz, 0x8018 > > test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010 > > (lldb) r > > Process 21312 launched: '/home/rjodin/work/dpu_tools/llvm/lldb/test/test' > (dpu) > > Process 21312 stopped > > * thread #1, name = 'DPUthread0', stop reason = Thread finished > > frame #0: 0x80a0 > > (lldb) dis -s 0x8000 > > error: Unable to find Disassembler plug-in for the 'x86_64' architecture. > > (lldb) dis -s 0x8000 -A dpu > > 0x8000: jnzid, 0x8020 > > 0x8008: move r0, 0xff > > 0x8010: release r0, 0x0, nz, 0x8018 > > 0x8018: subr0, r0, 0x1, pl, 0x8010 > > > > Any ideas about it? > > Thanks, > > Romaric > > > > On Wed, Jun 12, 2019 at 6:55 PM Ted Woodward wrote: > > The error is coming from source/Commands/CommandObjectDisassemble.cpp . > It’s not able to create the disassembler for your architecture. The call to > Disassembler::FindPlugin fails. > > My guess is something in the call to MCDisasmInstance::Create in > source/Plugins/Disassembler/llvm/DisassemblerLLVMC.cpp is failing. Step > through that and make sure everything there is working. > > > > Ted > > > > *
[lldb-dev] Adding a new architecture into LLDB
Hello everyone, I am trying to add a new architecture into LLDB. My architecture is a accelerator with its own ISA for which we have a LLVM backend (release 7.1). I have started by creating a new NativeProcessProtocol for my architecture. So I have a lldb-server that run on a x86, but which takes care of process of my architecture. I have forced it to use my NativeProcessProtocol. I have a issue with this method because as the lldb-server is compile to run on a x86, some part of the code think that it is managing x86 process. Maybe I am going in the wrong direction to add such new architecture to LLDB, I would be happy to try any other suggestions. If you are interested, you can have a look at my branch "dev/rjodin/lldb_dpu" in our forked repo of LLDB " https://github.com/upmem/lldb";. The branch is not clean, but it can help you understand what I did. Thanks, -- *Romaric JODIN* UPMEM *Software Engineer* ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] issue with StackFrame::GetSymbolContext
HI everyone,
I'm adding my architecture into lldb.
I'm having some trouble with the debug information on the stack frame.
LLDB is never displaying any source code. It seems that we I get in
"StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but
my "m_sc" does not contains the information needed about the module
("module_sp=0x0").
But LLDB can read the elf file and find information like here:
Process 21312 stopped
* thread #1, name = 'DPUthread0', stop reason = suspended
frame #0: 0x8018
test`__bootstrap:
test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
test[0x8020] <+32>: jgeu id, 0x3, 0x8058
test[0x8028] <+40>: jeqid, 0x2, 0x8038
test[0x8030] <+48>: boot id, 0x1
or here:
(lldb) b main
Breakpoint 1: where = test`main + 32 at test.c:29, address = 0x8080
Do someone get what I'm missing?
Thanks,
--
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] issue with StackFrame::GetSymbolContext
Thanks Jim, it helped a lot. But it bings other questions.
I managed to get the symbol by forcing the use of the DynamicLoaderStatic,
which is use only if the Strata is set to "eStrataRawImage".
What is "Strata" ?
Why is the Static DynamicLoader only use with the eStrataRawImage?
Right now, I don't feel the need to implement a DynamicLoader specific for
my backend as the static seems to be doing the job just fine. But maybe
I'll have to at some point.
Anyway, Thanks again, it helps me going forward with the implementation.
Romaric
On Tue, Jul 9, 2019 at 7:53 PM Jim Ingham wrote:
> It looks like you don't have a DynamicLoader plugin that tells lldb where
> your binaries ended up in memory when the process ran. The [ADDRESS] means
> we are reading instructions from memory not from the on-disk binary.
>
> Jim
>
>
> > On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > HI everyone,
> >
> > I'm adding my architecture into lldb.
> > I'm having some trouble with the debug information on the stack frame.
> > LLDB is never displaying any source code. It seems that we I get in
> "StackFrame::GetSymbolContext" "m_flags" is always set to "0x" but
> my "m_sc" does not contains the information needed about the module
> ("module_sp=0x0").
> > But LLDB can read the elf file and find information like here:
> >
> > Process 21312 stopped
> > * thread #1, name = 'DPUthread0', stop reason = suspended
> > frame #0: 0x8018
> > test`__bootstrap:
> > test[0x8018] <+24>: subr0, r0, 0x1, pl, 0x8010
> > test[0x8020] <+32>: jgeu id, 0x3, 0x8058
> > test[0x8028] <+40>: jeqid, 0x2, 0x8038
> > test[0x8030] <+48>: boot id, 0x1
> >
> > or here:
> >
> > (lldb) b main
> > Breakpoint 1: where = test`main + 32 at test.c:29, address = 0x8080
> >
> > Do someone get what I'm missing?
> >
> > Thanks,
> > --
> > Romaric JODIN
> > UPMEM
> > Software Engineer
> >
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
--
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Adding a new architecture into LLDB
Indeed, that's exactly what I've done. I've got a "lldb-server-dpu", and
the only modification I made to have it working as expected is to have a
second "liblldbHost.a" ("liblldbHostDpu.a"), with a single modification in
"HostInfoBase::ComputeHostArchitectureSupport" (
https://github.com/upmem/lldb/commit/d35bbb8376096fd3ab3047b1c5ec507c96731deb#diff-7a05d638d592248e1fbb10192911affbR298
)
Seems to work well for the moment.
Romaric
On Fri, Jul 12, 2019 at 11:11 PM Greg Clayton wrote:
>
>
> On Jun 18, 2019, at 7:08 AM, Romaric Jodin via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hello everyone,
>
> I am trying to add a new architecture into LLDB.
> My architecture is a accelerator with its own ISA for which we have a LLVM
> backend (release 7.1).
>
> I have started by creating a new NativeProcessProtocol for my
> architecture. So I have a lldb-server that run on a x86, but which takes
> care of process of my architecture. I have forced it to use my
> NativeProcessProtocol.
> I have a issue with this method because as the lldb-server is compile to
> run on a x86, some part of the code think that it is managing x86 process.
>
>
> Maybe I am going in the wrong direction to add such new architecture to
> LLDB, I would be happy to try any other suggestions.
>
>
> lldb-server is currently meant to build a native debugging GDB server that
> can be used with lldb. If you want to always build a cross build
> lldb-server for your architecture, you will want to add a new tool that
> gets built in the CMakeList.txt in the tools/lldb-server directory. You
> will need to build it into a different binary like "lldb-server-dpu". I am
> not sure how much trouble you will run into doing this though as much of
> the lldb-server build assumes things match the current host.
>
>
> If you are interested, you can have a look at my branch
> "dev/rjodin/lldb_dpu" in our forked repo of LLDB "
> https://github.com/upmem/lldb";. The branch is not clean, but it can help
> you understand what I did.
>
> Thanks,
> --
> *Romaric JODIN*
> UPMEM
> *Software Engineer*
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
--
*Romaric JODIN*
UPMEM
*Software Engineer*
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] test suite issue with Python2.7/3.5
Hi everyone, I'm trying to run the test suite on lldb and I'm having some issues with Python. I'm on branch 7.0. When I build lldb, I've got a folder "python3.5/site-packages" generated. So I believe that the build system found python3 in my environment. But when I run the testsuite (using "ninja check-lldb"), I've got this issue: Traceback (most recent call last): File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 113, in wrapper func(*args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/decorators.py", line 341, in wrapper return func(self, *args, **kwargs) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/functionalities/command_regex/TestCommandRegex.py", line 39, in test_command_regex child.expect_exact(prompt) File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/third_party/Python/module/pexpect-2.4/pexpect.py", line 1386, in expect_exact if type(pattern_list) in types.StringTypes or pattern_list in ( AttributeError: module 'types' has no attribute 'StringTypes' It seems that it's because the code in "pexpect.py" is not compatible with python3.5. If I force the system to use python2.7, I've got another issue because of the way "_lldb.so" is built (with python3.5): Traceback (most recent call last): File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/test/dotest.py", line 7, in lldbsuite.test.run_suite() File "/home/rjodin/work/dpu_tools/llvm/lldb/lldb/packages/Python/lldbsuite/test/dotest.py", line 1180, in run_suite import lldb File "/home/rjodin/package-sdk-2019.3.0/upmem-internal/usr/share/upmem/lib/python3.5/site-packages/lldb/__init__.py", line 39, in import _lldb ImportError: dynamic module does not define init function (init_lldb) What do I do wrong? Thanks, -- *Romaric JODIN* UPMEM *Software Engineer* ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] How to print message from lldb-server in lldb
Hi everyone, I'm trying to have my lldb-server to print a message, but in the terminal of the lldb (client) it is connected with. Is it possible? My lldb-server and the client are connected through the gdb-remote Plugin. Thanks, Romaric ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] issue with lldb9 and python3.5
Hi everyone, I have lldb crashing since I've updated to lldb9. Seems like there is a issue with python3.5. Everything seems to work fine with python3.7. Am I missing something? Or is it a known issue? $ lldb (lldb) script #0 0x7f3d324c9c2a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bfc2a) #1 0x7f3d324c7af5 llvm::sys::RunSignalHandlers() (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdaf5) #2 0x7f3d324c7c0c SignalHandler(int) (/home/rjodin/work/dpu_tools3/build/lib/libLLVM-9.so+0x6bdc0c) #3 0x7f3d31bfe0e0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110e0) #4 0x7f3d2d18f81b PyModule_GetState (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x6881b) #5 0x7f3d230e1621 _init (/usr/lib/python3.5/lib-dynload/ readline.cpython-35m-x86_64-linux-gnu.so+0x3621) #6 0x7f3d2e3dece1 rl_initialize (/usr/lib/x86_64-linux-gnu/libedit.so.2+0x1dce1) #7 0x7f3d230e1f3e _init (/usr/lib/python3.5/lib-dynload/ readline.cpython-35m-x86_64-linux-gnu.so+0x3f3e) #8 0x7f3d2d32d710 _PyImport_LoadDynamicModuleWithSpec (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x206710) #9 0x7f3d2d330fe7 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x209fe7) #10 0x7f3d2d198259 PyCFunction_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259) #11 0x7f3d2d2c8ff2 PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2) #12 0x7f3d2d38b074 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074) #13 0x7f3d2d2c7adf PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf) #14 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #15 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #16 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #17 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #18 0x7f3d2d38b074 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074) #19 0x7f3d2d38b153 PyEval_EvalCodeEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153) #20 0x7f3d2d21e558 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0xf7558) #21 0x7f3d2d2faa37 PyObject_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37) #22 0x7f3d2d2fce1b _PyObject_CallMethodIdObjArgs (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d5e1b) #23 0x7f3d2d32effa PyImport_ImportModuleLevelObject (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x207ffa) #24 0x7f3d2d2cd248 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a6248) #25 0x7f3d2d198279 PyCFunction_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71279) #26 0x7f3d2d2faa37 PyObject_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37) #27 0x7f3d2d389b77 PyEval_CallObjectWithKeywords (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x262b77) #28 0x7f3d2d2c57cb PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x19e7cb) #29 0x7f3d2d38b074 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074) #30 0x7f3d2d38b153 PyEval_EvalCodeEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153) #31 0x7f3d2d2c145b PyEval_EvalCode (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x19a45b) #32 0x7f3d2d2ce2cd (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a72cd) #33 0x7f3d2d198259 PyCFunction_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71259) #34 0x7f3d2d2c8ff2 PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a1ff2) #35 0x7f3d2d38b074 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074) #36 0x7f3d2d2c7adf PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a0adf) #37 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #38 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #39 0x7f3d2d2c96ad PyEval_EvalFrameEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a26ad) #40 0x7f3d2d38b074 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264074) #41 0x7f3d2d38b153 PyEval_EvalCodeEx (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x264153) #42 0x7f3d2d21e558 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0xf7558) #43 0x7f3d2d2faa37 PyObject_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37) #44 0x7f3d2d2fce1b _PyObject_CallMethodIdObjArgs (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d5e1b) #45 0x7f3d2d32effa PyImport_ImportModuleLevelObject (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x207ffa) #46 0x7f3d2d2cd248 (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1a6248) #47 0x7f3d2d198279 PyCFunction_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x71279) #48 0x7f3d2d2faa37 PyObject_Call (/usr/lib/x86_64-linux-gnu/libpython3.5m.so.1.0+0x1d3a37) #
