luajit-gdb: ValueError: sequence.index(x): x not in sequence #4828
Comments
|
@Buristan also faced the similar issue. Here are some artefacts: It looks like another issue with ancient Python support, since everything is OK on my Gentoo host: |
|
I don't know is correct it or not. And my experimental absolutely dirty changes: diff --git a/src/luajit-gdb.py b/src/luajit-gdb.py
index f142fc5..ed92fbe 100644
--- a/src/luajit-gdb.py
+++ b/src/luajit-gdb.py
@@ -669,10 +669,13 @@ def init(commands):
'until libluajit objfile is loaded\n')
gdb.events.new_objfile.connect(load)
return
-
+ e = None
try:
- gdb.events.new_objfile.disconnect(load)
- except:
+ e = gdb.events.new_objfile.disconnect(load)
+ import time
+ time.sleep(0.1)
+ except Exception as ex:
+ print(e, ex)
pass # was not connected
try: |
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jul 4, 2020
There was a mystic error when the extension was loaded against old gdb
versions build against Python 2:
| (gdb) source luajit-gdb.py
| Traceback (most recent call last):
| File "luajit-gdb.py", line 702, in <module>
| load(None)
| File "luajit-gdb.py", line 699, in load
| 'lj-gc': LJGC,
| File "luajit-gdb.py", line 687, in init
| command(name)
| File "luajit-gdb.py", line 468, in __init__
| gdb.write('{} command initialized\n'.format(name))
| ValueError: sequence.index(x): x not in sequence
I made a little investigation (for more info see the mentioned issue)
and found the next fun fact: the exception was raised much earlier to
<str.format>, more precisely in <gdb.events.new_objfile.disconnect>.
However, the handled exception is preserved until <str.format> call and
hits the condition underneath leading to the extension load failure.
As a result to avoid the exception raise, the special global variable is
introduced for legacy (i.e. Python 2) environment. It checks whether any
callback is associated with new_objfile event prior to disconnecting it.
This variable usage is encapsulated within two introduced routines:
<connect> and <disconnect> which are wrappers for ones provided by gdb.
Furthermore, after diving to gdb sources related to Python embedding, I
found that callbacks are grouped into an internal list. Previous
implementation appended the <load> function to this callback list on
each its unsuccessful call, but only the successful one is removes it
from the list. Thereby disconnect action is moved prior to connect one
so there is no more than one <load> instance kept in callback list.
Fixes tarantool/tarantool#4828
Reported-by: Oleg Babin <olegrok@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
|
@olegrok, thanks for your investigation, it pushed me to go a bit deeper. I applied the diff below and obtained the following output: diff --git a/src/luajit-gdb.py b/src/luajit-gdb.py
index f142fc5..93f9058 100644
--- a/src/luajit-gdb.py
+++ b/src/luajit-gdb.py
@@ -676,6 +676,11 @@ def init(commands):
pass # was not connected
try:
+ print("Normal person's loading log")
+ except:
+ print("Smoker's loading log")
+
+ try:
LJ_64 = str(gdb.parse_and_eval('IRT_PTR')) == 'IRT_P64'
LJ_FR2 = LJ_GC64 = str(gdb.parse_and_eval('IRT_PGC')) == 'IRT_P64'
except:gdb w/ Python 2.7.5gdb w/ Python 3.6.8The result looks freaking ridiculous to me. I tried to debug the case a little to find the root cause, but after some time digging the problem I can only state the following: it seems the exception raised within gdb --args gdb ./luajitAnd here is the difference: Python 2.7.5 doesn't purge the handled exception but Python 3.6.8 (at least) does As a result it hits the condition underneath the Finally, I've just added a custom |
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jul 6, 2020
There was a mystic error when the extension was loaded by the old gdb
versions built against Python 2:
| (gdb) source luajit-gdb.py
| Traceback (most recent call last):
| File "luajit-gdb.py", line 702, in <module>
| load(None)
| File "luajit-gdb.py", line 699, in load
| 'lj-gc': LJGC,
| File "luajit-gdb.py", line 687, in init
| command(name)
| File "luajit-gdb.py", line 468, in __init__
| gdb.write('{} command initialized\n'.format(name))
| ValueError: sequence.index(x): x not in sequence
I made a little investigation (for more info see the mentioned issue)
and found the next fun fact: the exception was raised much earlier to
<str.format>, more precisely in <gdb.events.new_objfile.disconnect>.
However, the handled exception is preserved until <str.format> call and
hits the condition underneath leading to the extension load failure.
As a result to avoid the exception, the special global variable is
introduced for legacy (i.e. Python 2) environment. It checks whether any
callback is associated with new_objfile event prior to disconnecting it.
This variable usage is encapsulated within two introduced routines:
<connect> and <disconnect> which are wrappers for ones provided by gdb.
Furthermore, after diving to gdb sources related to Python embedding, I
found that callbacks are grouped into an internal list. Previous
implementation appended the <load> function to this callback list on
each its unsuccessful call, but only the successful one is removes it
from the list. Thereby disconnect action is moved prior to connect one
so there is no more than one <load> instance kept in callback list.
Fixes tarantool/tarantool#4828
Reported-by: Oleg Babin <olegrok@tarantool.org>
Reviewed-by: Oleg Babin <olegrok@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jul 22, 2020
There was a mystic error when the extension was loaded by the old gdb
versions built against Python 2:
| (gdb) source luajit-gdb.py
| Traceback (most recent call last):
| File "luajit-gdb.py", line 702, in <module>
| load(None)
| File "luajit-gdb.py", line 699, in load
| 'lj-gc': LJGC,
| File "luajit-gdb.py", line 687, in init
| command(name)
| File "luajit-gdb.py", line 468, in __init__
| gdb.write('{} command initialized\n'.format(name))
| ValueError: sequence.index(x): x not in sequence
I made a little investigation (for more info see the mentioned issue)
and found the next fun fact: the exception was raised much earlier to
<str.format>, more precisely in <gdb.events.new_objfile.disconnect>.
However, the handled exception is preserved until <str.format> call and
hits the condition underneath leading to the extension load failure.
As a result to avoid the exception, the special global variable is
introduced for legacy (i.e. Python 2) environment. It checks whether any
callback is associated with new_objfile event prior to disconnecting it.
This variable usage is encapsulated within two introduced routines:
<connect> and <disconnect> which are wrappers for ones provided by gdb.
Furthermore, after diving to gdb sources related to Python embedding, I
found that callbacks are grouped into an internal list. Previous
implementation appended the <load> function to this callback list on
each its unsuccessful call, but only the successful one is removes it
from the list. Thereby disconnect action is moved prior to connect one
so there is no more than one <load> instance kept in callback list.
Fixes tarantool/tarantool#4828
Reported-by: Oleg Babin <olegrok@tarantool.org>
Reviewed-by: Oleg Babin <olegrok@tarantool.org>
Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
|
Introduced in tarantool/luajit in tarantool/luajit@ad1d444. The submodule was updated in tarantool in 2.6.0-12-gbc58c0679 (bc58c06), 2.5.1-4-g0c3f90bd2 (0c3f90b), 2.4.2-4-gae283d828 (ae283d8), 1.10.7-3-g2eddcb432 (2eddcb4). |
igormunkin
added a commit
to tarantool/luajit
that referenced
this issue
Jun 16, 2022
There was a mystic error when the extension was loaded by the old gdb
versions built against Python 2:
| (gdb) source luajit-gdb.py
| Traceback (most recent call last):
| File "luajit-gdb.py", line 702, in <module>
| load(None)
| File "luajit-gdb.py", line 699, in load
| 'lj-gc': LJGC,
| File "luajit-gdb.py", line 687, in init
| command(name)
| File "luajit-gdb.py", line 468, in __init__
| gdb.write('{} command initialized\n'.format(name))
| ValueError: sequence.index(x): x not in sequence
I made a little investigation (for more info see the mentioned issue)
and found the next fun fact: the exception was raised much earlier to
<str.format>, more precisely in <gdb.events.new_objfile.disconnect>.
However, the handled exception is preserved until <str.format> call and
hits the condition underneath leading to the extension load failure.
As a result to avoid the exception, the special global variable is
introduced for legacy (i.e. Python 2) environment. It checks whether any
callback is associated with new_objfile event prior to disconnecting it.
This variable usage is encapsulated within two introduced routines:
<connect> and <disconnect> which are wrappers for ones provided by gdb.
Furthermore, after diving to gdb sources related to Python embedding, I
found that callbacks are grouped into an internal list. Previous
implementation appended the <load> function to this callback list on
each its unsuccessful call, but only the successful one is removes it
from the list. Thereby disconnect action is moved prior to connect one
so there is no more than one <load> instance kept in callback list.
Fixes tarantool/tarantool#4828
Reported-by: Oleg Babin <olegrok@tarantool.org>
Reviewed-by: Oleg Babin <olegrok@tarantool.org>
Reviewed-by: Sergey Ostanevich <sergos@tarantool.org>
Signed-off-by: Igor Munkin <imun@tarantool.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tarantool version:
Tarantool 2.4.0-137-g9933c5d
Target: Linux-x86_64-Debug
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_BACKTRACE=OFF
Compiler: /usr/bin/cc /usr/bin/c++
flags: ' -fexceptions -funwind-tables -fno-common -fopenmp -msse2 -std=c11 -Wall
-Wextra -Wno-strict-aliasing -Wno-char-subscripts -Wno-format-truncation -fno-gnu89-inline
-Wno-cast-function-type -Werror'
OS version: centos-7 (docker run -it --cap-add=SYS_PTRACE --security-opt seccomp=unconfined tarantool/tarantool:2.x-centos7 bash)
Bug description:
After #4827 I decided fairly build Tarantool from source in Debug mode. Simply
cmake . && make -j && ./src/tarantooland got error that is shown above.The text was updated successfully, but these errors were encountered: