[asterisk-bugs] [JIRA] (ASTERISK-30039) cli: Targeted debug on startup deadlocks and creates unstable system

[N A (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-30039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

N A updated ASTERISK-30039:
---------------------------

    Attachment: full.txt

Okay, forget about ast_coredumper, I just did it manually with gdb and it worked fine:

gdb --batch -q -p 20926 -ex 'thread apply all bt full' -ex 'quit' > /tmp/full.txt

Attached is the full.txt. Something is seriously wrong. Literally every thread appears to be deadlocked. That would explain a lot!

> cli: Targeted debug on startup deadlocks and creates unstable system
> --------------------------------------------------------------------
>
>                 Key: ASTERISK-30039
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30039
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Logging
>    Affects Versions: 18.9.0
>            Reporter: N A
>            Assignee: Unassigned
>         Attachments: full.txt
>
>
> If, while Asterisk is starting, you attempt to use tab completion with "core set debug X <tab complete>", and you do this BEFORE Asterisk is fully ready, the CLI will deadlock and the system will become permanently unstable and fail to ever initialize. Not all commands do this but "core set debug X <tab complete>" does do it. Seems to be an "unsafe" operation if Asterisk is not ready for some reason.
> e.g. if you use SIGQUIT to exit the CLI and then go back into a remote console, if you run "core restart now" it will say no command found because the system never fully started so Asterisk is still not (and will never be) ready.
> Even ast_coredumper fails because it fails to get the PID and there isn't an option to manually specify it.
> This does reproduce consistently.



--
This message was sent by Atlassian JIRA
(v6.2#6252)