You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@mynewt.apache.org by "Vipul Rahane (JIRA)" <ji...@apache.org> on 2016/07/13 21:41:20 UTC
[jira] [Updated] (MYNEWT-334) reboot log can put newtmgr task into
an infinite loop
[ https://issues.apache.org/jira/browse/MYNEWT-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vipul Rahane updated MYNEWT-334:
--------------------------------
Description:
After an upgrade to the latest apache-mynewt-core, reset commands no longer worked. Issuing a reset via newtmgr would not reset the device and caused all subsequent newtmgr commands to timeout. The newtmgr task would enter an infinite loop. Here's an example stack trace when in the infinite loop.
{noformat}
(gdb) bt
#0 0x00003050 in ?? ()
#1 0x000174ae in log_append (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
data=0x20002740 <newtmgr_stack+3768>, data@entry=0x20002738 <newtmgr_stack+3760>, len=28) at log.c:125
#2 0x00017520 in log_printf (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
msg=0x1c14c "rsn:%s, cnt:%u, img:%u.%u.%u.%u") at log.c:155
#3 0x00017d70 in log_reboot (reason=reason@entry=0) at log_reboot.c:158
#4 0x00013cb8 in nmgr_reset (njb=0x2000405c <nmgr_task_jbuf>) at newtmgr_os.c:230
#5 0x00013838 in nmgr_handle_req (req=0x20003268 <default_mbuf_mpool_data>, nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:461
#6 nmgr_process (nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:500
#7 0x000138d0 in nmgr_task (arg=<optimized out>) at newtmgr.c:519
#8 0x00000000 in ?? ()
{noformat}
I was able to fix the problem by adding this code in my main()
reboot_init_handler(LOG_TYPE_STORAGE, 10);
I'm guessing the infinite loop is the while (1) loop in log_fcb_append.
It would be good to handle the case where the reboot log isn't initialized more gracefully.
was:
After an upgrade to the latest apache-mynewt-core, reset commands no longer worked. Issuing a reset via newtmgr would not reset the device and caused all subsequent newtmgr commands to timeout. The newtmgr task would enter an infinite loop. Here's an example stack trace when in the infinite loop.
{no format}
(gdb) bt
#0 0x00003050 in ?? ()
#1 0x000174ae in log_append (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
data=0x20002740 <newtmgr_stack+3768>, data@entry=0x20002738 <newtmgr_stack+3760>, len=28) at log.c:125
#2 0x00017520 in log_printf (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
msg=0x1c14c "rsn:%s, cnt:%u, img:%u.%u.%u.%u") at log.c:155
#3 0x00017d70 in log_reboot (reason=reason@entry=0) at log_reboot.c:158
#4 0x00013cb8 in nmgr_reset (njb=0x2000405c <nmgr_task_jbuf>) at newtmgr_os.c:230
#5 0x00013838 in nmgr_handle_req (req=0x20003268 <default_mbuf_mpool_data>, nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:461
#6 nmgr_process (nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:500
#7 0x000138d0 in nmgr_task (arg=<optimized out>) at newtmgr.c:519
#8 0x00000000 in ?? ()
{no format}
I was able to fix the problem by adding this code in my main()
reboot_init_handler(LOG_TYPE_STORAGE, 10);
I'm guessing the infinite loop is the while (1) loop in log_fcb_append.
It would be good to handle the case where the reboot log isn't initialized more gracefully.
> reboot log can put newtmgr task into an infinite loop
> -----------------------------------------------------
>
> Key: MYNEWT-334
> URL: https://issues.apache.org/jira/browse/MYNEWT-334
> Project: Mynewt
> Issue Type: Bug
> Components: Newtmgr
> Affects Versions: v0_9_0
> Reporter: Todd Mitton
> Assignee: Vipul Rahane
> Priority: Minor
>
> After an upgrade to the latest apache-mynewt-core, reset commands no longer worked. Issuing a reset via newtmgr would not reset the device and caused all subsequent newtmgr commands to timeout. The newtmgr task would enter an infinite loop. Here's an example stack trace when in the infinite loop.
> {noformat}
> (gdb) bt
> #0 0x00003050 in ?? ()
> #1 0x000174ae in log_append (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
> data=0x20002740 <newtmgr_stack+3768>, data@entry=0x20002738 <newtmgr_stack+3760>, len=28) at log.c:125
> #2 0x00017520 in log_printf (log=log@entry=0x2000132c <reboot_log>, module=module@entry=6, level=level@entry=4,
> msg=0x1c14c "rsn:%s, cnt:%u, img:%u.%u.%u.%u") at log.c:155
> #3 0x00017d70 in log_reboot (reason=reason@entry=0) at log_reboot.c:158
> #4 0x00013cb8 in nmgr_reset (njb=0x2000405c <nmgr_task_jbuf>) at newtmgr_os.c:230
> #5 0x00013838 in nmgr_handle_req (req=0x20003268 <default_mbuf_mpool_data>, nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:461
> #6 nmgr_process (nt=0x20004120 <g_nmgr_shell_transport>) at newtmgr.c:500
> #7 0x000138d0 in nmgr_task (arg=<optimized out>) at newtmgr.c:519
> #8 0x00000000 in ?? ()
> {noformat}
> I was able to fix the problem by adding this code in my main()
> reboot_init_handler(LOG_TYPE_STORAGE, 10);
> I'm guessing the infinite loop is the while (1) loop in log_fcb_append.
> It would be good to handle the case where the reboot log isn't initialized more gracefully.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)