gdb.error: Alias already exists: db

[c02y]

Unable to use .gdbinit in gdb:

(gdb) source ~/Public/gdb-dashboard/.gdbinit
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 385, in start
  File "<string>", line 288, in load_modules
  File "<string>", line 484, in __init__
ValueError: zero length field name in format
~/Public/gdb-dashboard/.gdbinit:1402: Error in sourced command file:
Error while executing Python code.
>>>

gdb-v7.7.1

---

UPDATE:

$ gdb -ex 'python import sys; print(sys.version)' -ex quit
2.6.6 (r266:84292, Nov 22 2013, 12:11:10)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]

But I compiled using python3.3 last year according to #1 (comment) , weird, since I'm using anaconda to manager python versions and packages recently, but I didn't remove any other python versions installed in /usr/local, don't know when gdb is changed.

After recompile it using python3.3, it works now.

---

UPDATE2:

Now gdb can use .gdbinit, but when I modified .gdbinit outside gdb such as adding/modifying an alias or function and tried to reload the .gdbinit, this happens:

>>> source ~/Public/gdb-dashboard/.gdbinit
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 389, in start
  File "<string>", line 128, in run
gdb.error: Alias already exists: db
~/Public/gdb-dashboard/.gdbinit:1402: Error in sourced command file:
Error while executing Python code.

Is it possible to fix this problem?

[cyrus-and]

ValueError: zero length field name in format

Yes, this is clearly due to the fact that you were using Python 2.6.

since I'm using anaconda to manager python versions and packages recently

The Python version used by GDB is not the one present in your system but the one that has been chosen during compilation.

but when I modified .gdbinit outside gdb such as adding/modifying an alias or function

You should not modify .gdbinit unless there's no other way, you can add your personal aliases in .gdbinit.d/init.

Anyway this error happens because the db alias already exists, so if you have not redefined it (try with a clean setup; remove .gdbinit*) then maybe your newly compiled version of GDB already defines db as an alias or command. Are you still using v7.7.1?

[c02y]

Yes, still using gdb v7.7.1

[cyrus-and]

Does a clean setup help?

[c02y]

Clean setup? You mean running gdb without loading .gdbinit?

[cyrus-and]

No, I mean removing custom init files in .gdbinit.d/ (if any) and reverting to the vanilla .gdbinit if you made local modifications.

[cyrus-and]

FWIW I tried compiling GDB v7.7.1 against Python v3.3.0 and still I cannot reproduce this. Another possible cause is that you're sourcing the dashboard twice. Double-check your init files.

[c02y]

I don't have ~/.gdbinit.d directory, only the .gdbinit file from you repo.

And yes, I did source the dashboard more than once, I mentioned reload behavior in the last UPDATE part of the first post content of this issue, when I'm debugging a program, I add/modify a function to the .gdbinit file, and use source command to make it work (it is already sourced in the current gdb session), it says "gdb.error: Alias already exists: db".

The source command, in my opinion, is like the source in bash-shell, if you modify .bashrc, source makes the modification work, it shouldn't print a message that `Alias already exists" or something like that.

[cyrus-and]

The fact is that the dashboard is not meant to be reloaded, actually it's not even meant to be altered by editing .gdbinit (and we've already discussed this in #48...).

As I said, the expected place to put custom aliases and functions is in .gdbinit.d/ but even in this case if you source the dashboard twice you'll end up with the same error message since files in .gdbinit.d/ are sourced again as well. And I don't really have control about that, that is, the evaluation is interrupted by an exception.

Said that, I'm going to get rid of that alias altogether, which is kind of useless since partial commands are supported natively by GDB so da, dash, etc. all resolve to dashboard. Users willing to specify a custom alias can just add the following to their initialization file (bearing in mind the aforementioned behavior):

alias -a db = dashboard