Bug ID 27020
Summary “command alias r run” causes an assert
Product lldb
Version unspecified
Hardware PC
OS Windows NT
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@lists.llvm.org
Reporter ted.woodward@codeaurora.org
CC llvm-bugs@lists.llvm.org
Classification Unclassified
This happens on Linux and Windows; probably all platforms.
>bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) command alias r run
warning: Overwriting existing definition for 'r'.
(lldb) r
CommandAlias::Execute is not to be called
UNREACHABLE executed at
/local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
Abort (core dumped)
Ted,
unfortunately I am more than a little busy at the moment - and it would probably be a day or two before I can actually take a meaningful look at this
On the other hand, I suspect I know what the issue you’re running into is
Due to existing complexity in the interpreter, a CommandAlias isn’t directly executable. So, we have CommandInterpreter::BuildAliasResult() which is the function that is responsible for taking an alias apart and passing the pieces to the command interpreter for actual execution.
In your case, what is happening is that you have an alias to an alias, so the underlying command is actually an alias
What one would need to try and do is write a recursive function that, given an alias, potentially nested, spits out the final OptionArgVectorSP and non-alias CommandObject
It is something I can work on, but as I said, it’s going to be a few days before I can get to it. So, if you want to try your hand at a patch to this effect, I would be most happy to take a look at it
Apologies for the breakage and thanks for reporting this
- Enrico
Ted,
I think this is fixed by r264096
Can you try and make sure it works for you?
The assert is gone – the alias to an alias behaves as expected.
There is one issue with my testcase, “command alias r run”. That’s “help r”. The last line is “‘r’ is an abbreviation for ‘run -c /bin/sh --’”, but that’s not true. ‘run’ is an abbreviation for ‘process launch -c /bin/sh --’, and r is an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an abbreviation for ‘process launch –c /bin/sh – -c /bin/sh’.
Thanks for the quick fix!
Ted
The assert is gone – the alias to an alias behaves as expected.
Glad to hear! I put in a test case just to make sure we don’t regress on this in the future
There is one issue with my testcase, “command alias r run”. That’s “help r”. The last line is “'r' is an abbreviation for 'run -c /bin/sh --'”, but that’s not true. ‘run’ is an abbreviation for 'process launch -c /bin/sh --', and r is an abbreviation for ‘run’. From that help you’d infer that ‘r’ was an abbreviation for ‘process launch –c /bin/sh -- -c /bin/sh’.
I am not seeing that one - for me it just says 'r' is an abbreviation for ‘run'
With that said, I did make another patch following the one that fixes your issue
I’ll keep an eye out for this kind of issue!
Thanks for the quick fix!
You’re welcome!
And obviously thanks to you for finding these issues out!
Ted
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
From: egranata@apple.com [mailto:egranata@apple.com]
Sent: Tuesday, March 22, 2016 4:14 PM
To: Ted Woodward <ted.woodward@codeaurora.org>
Cc: LLDB <lldb-dev@lists.llvm.org>
Subject: Re: [lldb-dev] [Bug 27020] New: "command alias r run" causes an assert
Ted,
I think this is fixed by r264096
Can you try and make sure it works for you?
Bug ID
27020 <27020 – "command alias r run" causes an assert;
Summary
"command alias r run" causes an assert
Product
lldb
Version
unspecified
Hardware
PC
OS
Windows NT
Status
NEW
Severity
normal
Priority
P
Component
All Bugs
Assignee
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
Reporter
ted.woodward@codeaurora.org <mailto:ted.woodward@codeaurora.org>
CC
llvm-bugs@lists.llvm.org <mailto:llvm-bugs@lists.llvm.org>
Classification
Unclassified
This happens on Linux and Windows; probably all platforms.
>bin/lldb /bin/ls
(lldb) target create "/bin/ls"
Current executable set to '/bin/ls' (x86_64).
(lldb) command alias r run
warning: Overwriting existing definition for 'r'.
(lldb) r
CommandAlias::Execute is not to be called
UNREACHABLE executed at
/local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181!
Abort (core dumped)
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
lldb-dev Info Page
Ted,
unfortunately I am more than a little busy at the moment - and it would probably be a day or two before I can actually take a meaningful look at this
On the other hand, I suspect I know what the issue you’re running into is
Due to existing complexity in the interpreter, a CommandAlias isn’t directly executable. So, we have CommandInterpreter::BuildAliasResult() which is the function that is responsible for taking an alias apart and passing the pieces to the command interpreter for actual execution.
In your case, what is happening is that you have an alias to an alias, so the underlying command is actually an alias
What one would need to try and do is write a recursive function that, given an alias, potentially nested, spits out the final OptionArgVectorSP and non-alias CommandObject
It is something I can work on, but as I said, it’s going to be a few days before I can get to it. So, if you want to try your hand at a patch to this effect, I would be most happy to take a look at it
Apologies for the breakage and thanks for reporting this
- Enrico
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>
lldb-dev Info Page
Thanks,
- Enrico
egranata@.com <mailto:egranata@> 
27683
Thanks,
- Enrico
egranata@.com 27683
Ted Woodward changed bug 27020
What | Removed | Added |
- | - | - |
Status | NEW | RESOLVED |
Resolution | — | FIXED |
Comment # 1 on bug 27020 from Ted Woodward
Fixed by Enrico Granata in r265096