Re: [lldb-dev] issue with lldb9 and python3.5

[Pavel Labath via lldb-dev]

On 30/10/2019 11:18, Kamil Rytarowski wrote:

On 30.10.2019 11:06, Pavel Labath wrote:

On 29/10/2019 21:40, Christos Zoulas wrote:

On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
-- Subject: Re: [lldb-dev] issue with lldb9 and python3.5

| On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
| > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
| >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
| >
| > I investigated the bug yesterday, and filled some of my
discoveries in
| >
| >  https://bugs.llvm.org/show_bug.cgi?id=43830
| >
| > TLDR: libpython uses libreadline and lldb uses libedit, and that's
a mess.
|
| Hey Christos,
|
| could I bother you to take a look at this python PR
| <https://github.com/python/cpython/pull/16986>, and the related lldb
bug
| <https://bugs.llvm.org/show_bug.cgi?id=43830>?
|
| The executive summary is that there is an incompatibility between
| readline and its libedit emulation, which python needs to work around.
| Is there any way this can be fixed in libedit?
|
| I guess the presence of the workaround will make the fix tricky,
because
| then the workaround will be wrong for the "fixed" libedit, but it's
| still probably worth it to try to resolve this somehow.
|
| WDYT?

I don't know what I have to do here. Can someone explain to me what the
issue is?


I haven't dug into this (maybe Serge can explain in more detail), but I
think this comment (Modules/readline.c in python sources) gives a
general overview of the problem. Ignore the "On OSX" part, the same
should apply to any OS.

/*
  * It is possible to link the readline module to the readline
  * emulation library of editline/libedit.
  *
  * On OSX this emulation library is not 100% API compatible
  * with the "real" readline and cannot be detected at compile-time,
  * hence we use a runtime check to detect if we're using libedit
  *
  * Currently there is one known API incompatibility:
  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
  *   index with older versions of libedit's emulation.
  * - Note that replace_history and remove_history use a 0-based index
  *   with both implementations.
  */

Furthermore, you can probably look at every instance of
if(using_libedit_emulation) in that file (or via this link
<https://github.com/python/cpython/pull/16986/commits/3f325105d21af7cb8fd85de46af439f8579e6d7a#diff-41a8081584647e8f0451b4937c11ce71L53>),
as each one indicates a workaround for some libedit incompatibility. It
looks like not all of them are still relevant, as it seems some of them
are there just for the sake of old libedit bugs which have since been
fixed, but it looks like at least some of them are. Serge, can you tell
what exactly was the problem which caused the crash?

pl


Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.




Well, I was hoping that for someone intimately familiar with libedit 
(i.e., Christos) the difference in behavior would be obvious from just 
looking at that patch. :) But, of course, I can't make anyone do 
anything (nor I want to do that), so if fixing/figuring that out 
requires more time than you're willing to devote to that right now, then 
yes, I guess it means I or someone else will have to dive in and figure 
out what's wrong (eventually).


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 30.10.2019 11:06, Pavel Labath wrote:
> On 29/10/2019 21:40, Christos Zoulas wrote:
>> On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
>> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
>>
>> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
>> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
>> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
>> | >
>> | > I investigated the bug yesterday, and filled some of my
>> discoveries in
>> | >
>> | >  https://bugs.llvm.org/show_bug.cgi?id=43830
>> | >
>> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's
>> a mess.
>> |
>> | Hey Christos,
>> |
>> | could I bother you to take a look at this python PR
>> | <https://github.com/python/cpython/pull/16986>, and the related lldb
>> bug
>> | <https://bugs.llvm.org/show_bug.cgi?id=43830>?
>> |
>> | The executive summary is that there is an incompatibility between
>> | readline and its libedit emulation, which python needs to work around.
>> | Is there any way this can be fixed in libedit?
>> |
>> | I guess the presence of the workaround will make the fix tricky,
>> because
>> | then the workaround will be wrong for the "fixed" libedit, but it's
>> | still probably worth it to try to resolve this somehow.
>> |
>> | WDYT?
>>
>> I don't know what I have to do here. Can someone explain to me what the
>> issue is?
> 
> I haven't dug into this (maybe Serge can explain in more detail), but I
> think this comment (Modules/readline.c in python sources) gives a
> general overview of the problem. Ignore the "On OSX" part, the same
> should apply to any OS.
> 
> /*
>  * It is possible to link the readline module to the readline
>  * emulation library of editline/libedit.
>  *
>  * On OSX this emulation library is not 100% API compatible
>  * with the "real" readline and cannot be detected at compile-time,
>  * hence we use a runtime check to detect if we're using libedit
>  *
>  * Currently there is one known API incompatibility:
>  * - 'get_history' has a 1-based index with GNU readline, and a 0-based
>  *   index with older versions of libedit's emulation.
>  * - Note that replace_history and remove_history use a 0-based index
>  *   with both implementations.
>  */
> 
> Furthermore, you can probably look at every instance of
> if(using_libedit_emulation) in that file (or via this link
> <https://github.com/python/cpython/pull/16986/commits/3f325105d21af7cb8fd85de46af439f8579e6d7a#diff-41a8081584647e8f0451b4937c11ce71L53>),
> as each one indicates a workaround for some libedit incompatibility. It
> looks like not all of them are still relevant, as it seems some of them
> are there just for the sake of old libedit bugs which have since been
> fixed, but it looks like at least some of them are. Serge, can you tell
> what exactly was the problem which caused the crash?
> 
> pl

Is this a packaging issue?

There are good reasons to use libedit as a gnu readline drop in
replacement. The most important one is certainly saner licensing state
as gnu readline is GPLv3 and it makes it incompatible with at least
GPLv2 users (there are users that pick old gnureadline GPLv2 around).

If there are known incompatibilities, I think (not speaking on behalf of
Christos) it would be best to contribute patches with rationale. Generic
call for compatibility might not work well.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Pavel Labath via lldb-dev]

On 29/10/2019 21:40, Christos Zoulas wrote:

On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
-- Subject: Re: [lldb-dev] issue with lldb9 and python3.5

| On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
| > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
| >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
| >
| > I investigated the bug yesterday, and filled some of my discoveries in
| >
| >  https://bugs.llvm.org/show_bug.cgi?id=43830
| >
| > TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.
|
| Hey Christos,
|
| could I bother you to take a look at this python PR
| <https://github.com/python/cpython/pull/16986>, and the related lldb bug
| <https://bugs.llvm.org/show_bug.cgi?id=43830>?
|
| The executive summary is that there is an incompatibility between
| readline and its libedit emulation, which python needs to work around.
| Is there any way this can be fixed in libedit?
|
| I guess the presence of the workaround will make the fix tricky, because
| then the workaround will be wrong for the "fixed" libedit, but it's
| still probably worth it to try to resolve this somehow.
|
| WDYT?

I don't know what I have to do here. Can someone explain to me what the
issue is?


I haven't dug into this (maybe Serge can explain in more detail), but I 
think this comment (Modules/readline.c in python sources) gives a 
general overview of the problem. Ignore the "On OSX" part, the same 
should apply to any OS.


/*
 * It is possible to link the readline module to the readline
 * emulation library of editline/libedit.
 *
 * On OSX this emulation library is not 100% API compatible
 * with the "real" readline and cannot be detected at compile-time,
 * hence we use a runtime check to detect if we're using libedit
 *
 * Currently there is one known API incompatibility:
 * - 'get_history' has a 1-based index with GNU readline, and a 0-based
 *   index with older versions of libedit's emulation.
 * - Note that replace_history and remove_history use a 0-based index
 *   with both implementations.
 */

Furthermore, you can probably look at every instance of 
if(using_libedit_emulation) in that file (or via this link 
<https://github.com/python/cpython/pull/16986/commits/3f325105d21af7cb8fd85de46af439f8579e6d7a#diff-41a8081584647e8f0451b4937c11ce71L53>), 
as each one indicates a workaround for some libedit incompatibility. It 
looks like not all of them are still relevant, as it seems some of them 
are there just for the sake of old libedit bugs which have since been 
fixed, but it looks like at least some of them are. Serge, can you tell 
what exactly was the problem which caused the crash?


pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Kamil Rytarowski via lldb-dev]

On 29.10.2019 21:40, Christos Zoulas wrote:
> On Oct 29,  6:54pm, pa...@labath.sk (Pavel Labath) wrote:
> -- Subject: Re: [lldb-dev] issue with lldb9 and python3.5
> 
> | On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:
> | > On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
> | >> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.
> | > 
> | > I investigated the bug yesterday, and filled some of my discoveries in
> | > 
> | >  https://bugs.llvm.org/show_bug.cgi?id=43830
> | > 
> | > TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.
> | 
> | Hey Christos,
> | 
> | could I bother you to take a look at this python PR 
> | <https://github.com/python/cpython/pull/16986>, and the related lldb bug 
> | <https://bugs.llvm.org/show_bug.cgi?id=43830>?
> | 
> | The executive summary is that there is an incompatibility between 
> | readline and its libedit emulation, which python needs to work around. 
> | Is there any way this can be fixed in libedit?
> | 
> | I guess the presence of the workaround will make the fix tricky, because 
> | then the workaround will be wrong for the "fixed" libedit, but it's 
> | still probably worth it to try to resolve this somehow.
> | 
> | WDYT?
> 
> I don't know what I have to do here. Can someone explain to me what the
> issue is?
> 
> christos
> 

Is this a packaging issue? There are good reasons to use libedit as a
gnu readline replacement. I am not sure how complete it is here, but
there is definitely better licensing (at least from the GPLv3 vs GPLv2
incompatibility point of view - certain projects must use one version,
others the other one). If there are some nits in the readline compat,
better to fix the editline code for general benefit.



signature.asc
Description: OpenPGP digital signature
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Pavel Labath via lldb-dev]

On 29/10/2019 09:31, Serge Guelton via lldb-dev wrote:

On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:

+1 Yes, for Windows, I'd be happy if we said Python 3.6+.


I investigated the bug yesterday, and filled some of my discoveries in

 https://bugs.llvm.org/show_bug.cgi?id=43830

TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.


Hey Christos,

could I bother you to take a look at this python PR 
, and the related lldb bug 
?


The executive summary is that there is an incompatibility between 
readline and its libedit emulation, which python needs to work around. 
Is there any way this can be fixed in libedit?


I guess the presence of the workaround will make the fix tricky, because 
then the workaround will be wrong for the "fixed" libedit, but it's 
still probably worth it to try to resolve this somehow.


WDYT?

pavel
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Serge Guelton via lldb-dev]

On Mon, Oct 28, 2019 at 10:09:53AM -0700, Adrian McCarthy wrote:
> +1 Yes, for Windows, I'd be happy if we said Python 3.6+.

I investigated the bug yesterday, and filled some of my discoveries in

https://bugs.llvm.org/show_bug.cgi?id=43830

TLDR: libpython uses libreadline and lldb uses libedit, and that's a mess.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] issue with lldb9 and python3.5

[Ted Woodward via lldb-dev]

Internally on Windows we use Python 3.5.1. I just ran our latest nightly, and 
was able to run the script interpreter in lldb without issues.

I want to upgrade to 3.7.x, but I need to get permission from our lawyers to 
ship it. Looking forward to that…

From: lldb-dev  On Behalf Of Adrian McCarthy 
via lldb-dev
Sent: Monday, October 28, 2019 12:10 PM
To: Jonas Devlieghere 
Cc: Serge Guelton ; LLDB Dev 
Subject: [EXT] Re: [lldb-dev] issue with lldb9 and python3.5

+1 Yes, for Windows, I'd be happy if we said Python 3.6+.

On Mon, Oct 28, 2019 at 10:07 AM Jonas Devlieghere via lldb-dev 
mailto:lldb-dev@lists.llvm.org>> wrote:
On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere
mailto:jo...@devlieghere.com>> wrote:
>
> On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard 
> mailto:tstel...@redhat.com>> wrote:
> >
> > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > > and Python 3.7. I'm sorry if we forgot that in the release notes.
> > >
> >
> > Is there a specific reason why 3.5 is not supported?  Is it
> > because of this issue?
>
> Not really other than the lack of testing/CI.
>
> - The Linux bots are all running with Python 2.7.
> - I know that on macOS we ran into issues with some older versions. I
> don't remember if it was this particular issue and I'm not even sure
> if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
> all run with Python 3.7.
> - Stella's Windows bot is running Python 3.6 so we should consider
> that supported as well.

For completeness, Python 2.7 is not supported on Windows at all. The
docs specify Python 3.5 or later. Maybe we should bump that to 3.6
too?

>
> >
> > -Tom
> >
> > > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> > > mailto:lldb-dev@lists.llvm.org>> wrote:
> > >>
> > >> + lldb-dev
> > >>
> > >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> > >>>> 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?
> > >>>>
> > >>>
> > >>> We have seen this too with python 3.6, but we haven't found the root 
> > >>> cause yet.
> > >>> For now, we've worked around this by disabling the readline module with 
> > >>> the
> > >>> attached patch.
> > >>>
> > >>> -Tom
> > >>>
> > >>>> $ 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<http://readline.cpython-35m-x86_64-linux-gnu.so>
> > >>>>  <http://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<http://readline.cpython-35m-x86_64-linux-gnu.so>
> > >>>>  <http://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)
> &g

Re: [lldb-dev] issue with lldb9 and python3.5

[Adrian McCarthy via lldb-dev]

+1 Yes, for Windows, I'd be happy if we said Python 3.6+.

On Mon, Oct 28, 2019 at 10:07 AM Jonas Devlieghere via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere
>  wrote:
> >
> > On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard 
> wrote:
> > >
> > > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > > > and Python 3.7. I'm sorry if we forgot that in the release notes.
> > > >
> > >
> > > Is there a specific reason why 3.5 is not supported?  Is it
> > > because of this issue?
> >
> > Not really other than the lack of testing/CI.
> >
> > - The Linux bots are all running with Python 2.7.
> > - I know that on macOS we ran into issues with some older versions. I
> > don't remember if it was this particular issue and I'm not even sure
> > if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
> > all run with Python 3.7.
> > - Stella's Windows bot is running Python 3.6 so we should consider
> > that supported as well.
>
> For completeness, Python 2.7 is not supported on Windows at all. The
> docs specify Python 3.5 or later. Maybe we should bump that to 3.6
> too?
>
> >
> > >
> > > -Tom
> > >
> > > > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> > > >  wrote:
> > > >>
> > > >> + lldb-dev
> > > >>
> > > >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > > >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> > >  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?
> > > 
> > > >>>
> > > >>> We have seen this too with python 3.6, but we haven't found the
> root cause yet.
> > > >>> For now, we've worked around this by disabling the readline module
> with the
> > > >>> attached patch.
> > > >>>
> > > >>> -Tom
> > > >>>
> > >  $ 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 <
> http://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 <
> http://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 

Re: [lldb-dev] issue with lldb9 and python3.5

[Jonas Devlieghere via lldb-dev]

On Mon, Oct 28, 2019 at 10:04 AM Jonas Devlieghere
 wrote:
>
> On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard  wrote:
> >
> > On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > > and Python 3.7. I'm sorry if we forgot that in the release notes.
> > >
> >
> > Is there a specific reason why 3.5 is not supported?  Is it
> > because of this issue?
>
> Not really other than the lack of testing/CI.
>
> - The Linux bots are all running with Python 2.7.
> - I know that on macOS we ran into issues with some older versions. I
> don't remember if it was this particular issue and I'm not even sure
> if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
> all run with Python 3.7.
> - Stella's Windows bot is running Python 3.6 so we should consider
> that supported as well.

For completeness, Python 2.7 is not supported on Windows at all. The
docs specify Python 3.5 or later. Maybe we should bump that to 3.6
too?

>
> >
> > -Tom
> >
> > > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> > >  wrote:
> > >>
> > >> + lldb-dev
> > >>
> > >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> >  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?
> > 
> > >>>
> > >>> We have seen this too with python 3.6, but we haven't found the root 
> > >>> cause yet.
> > >>> For now, we've worked around this by disabling the readline module with 
> > >>> the
> > >>> attached patch.
> > >>>
> > >>> -Tom
> > >>>
> >  $ 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)
> >    

Re: [lldb-dev] issue with lldb9 and python3.5

[Jonas Devlieghere via lldb-dev]

On Mon, Oct 28, 2019 at 9:32 AM Tom Stellard  wrote:
>
> On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> > Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> > and Python 3.7. I'm sorry if we forgot that in the release notes.
> >
>
> Is there a specific reason why 3.5 is not supported?  Is it
> because of this issue?

Not really other than the lack of testing/CI.

- The Linux bots are all running with Python 2.7.
- I know that on macOS we ran into issues with some older versions. I
don't remember if it was this particular issue and I'm not even sure
if that was using Python 3.5 or Python 3.6. Our bots on GreenDragon
all run with Python 3.7.
- Stella's Windows bot is running Python 3.6 so we should consider
that supported as well.

>
> -Tom
>
> > On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
> >  wrote:
> >>
> >> + lldb-dev
> >>
> >> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> >>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
>  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?
> 
> >>>
> >>> We have seen this too with python 3.6, but we haven't found the root 
> >>> cause yet.
> >>> For now, we've worked around this by disabling the readline module with 
> >>> the
> >>> attached patch.
> >>>
> >>> -Tom
> >>>
>  $ 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 

Re: [lldb-dev] issue with lldb9 and python3.5

[Tom Stellard via lldb-dev]

On 10/28/2019 09:29 AM, Jonas Devlieghere wrote:
> Yes, Python 3.5 is not supported. We "officially" support Python 2.7
> and Python 3.7. I'm sorry if we forgot that in the release notes.
> 

Is there a specific reason why 3.5 is not supported?  Is it
because of this issue?

-Tom

> On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
>  wrote:
>>
>> + lldb-dev
>>
>> On 10/28/2019 07:06 AM, Tom Stellard wrote:
>>> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
 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?

>>>
>>> We have seen this too with python 3.6, but we haven't found the root cause 
>>> yet.
>>> For now, we've worked around this by disabling the readline module with the
>>> attached patch.
>>>
>>> -Tom
>>>
 $ 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 
 

Re: [lldb-dev] issue with lldb9 and python3.5

[Jonas Devlieghere via lldb-dev]

Yes, Python 3.5 is not supported. We "officially" support Python 2.7
and Python 3.7. I'm sorry if we forgot that in the release notes.

On Mon, Oct 28, 2019 at 7:06 AM Tom Stellard via lldb-dev
 wrote:
>
> + lldb-dev
>
> On 10/28/2019 07:06 AM, Tom Stellard wrote:
> > On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
> >> 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?
> >>
> >
> > We have seen this too with python 3.6, but we haven't found the root cause 
> > yet.
> > For now, we've worked around this by disabling the readline module with the
> > attached patch.
> >
> > -Tom
> >
> >> $ 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 

Re: [lldb-dev] issue with lldb9 and python3.5

[Tom Stellard via lldb-dev]

+ lldb-dev

On 10/28/2019 07:06 AM, Tom Stellard wrote:
> On 10/28/2019 03:50 AM, Romaric Jodin via lldb-dev wrote:
>> 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?
>>
> 
> We have seen this too with python 3.6, but we haven't found the root cause 
> yet.
> For now, we've worked around this by disabling the readline module with the
> attached patch.
> 
> -Tom
> 
>> $ 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 
>> 

[lldb-dev] issue with lldb9 and python3.5

[Romaric Jodin via lldb-dev]

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)