tabemann / zeptoforth

A not-so-small Forth for Cortex-M

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

NTP client breaks task monitor

pkoning2 opened this issue · comments

I tried out the SNTP client and it works fine. But then I decided to see how it shows up in the task monitor. The answer is: it breaks the task monitor.
Test procedure: load the ntp module and the ntp test program. Start the monitor. Confirm it's working by sending attention-t. Start the NTP client, which works. (I slightly tweaked it by setting its repeat interval to 10 seconds, and subtracting ntp-internal::secs-between-1900-and-1970 from the reported time to make it a Unix time.) I then entered attention-t again. That produced the monitor header but nothing further, and things are hung. When I run that test in zeptocom, it is sufficiently stuck that the "Reboot" signal has no effect.


  ok
monitor::start-monitor  ok

*** TASKS ***
task     name                     priority state      until       delay
         rstack-size rstack-used stack-size stack-used dict-size  dict-used  
cpu 0:
20041690 monitor                     32767 running                           
                 512         116        128      59189        320        244
20041988 main                            0 ready                             
                1024         140        512       1156     167916      99220
cpu 1:  ok
s" xxxxx" s" yyyyy" pico-w-net-ntp::start-client 
Discovering IPv4 address...
IPv4 address: 192.168.10.253                                                    
IPv4 netmask: 255.255.255.0                                                     
Gateway IPv4 address: 192.168.10.1                                              
DNS server IPv4 address: 192.168.10.1 ok                                        
1702751944,3704394698 1702751954,3778444698 1702751964,3841574697 1702751974,3 9
08444698 1702751984,3973274698                                                  
*** TASKS ***                                                                   
task     name                     priority state      until       delay         
         rstack-size rstack-used stack-size stack-used dict-size  dict-used     
c

It turned out that the task monitor was not given much space to store task info (it collects all the task info for a given CPU at once before displaying it, and the NTP client requires quite a few tasks overall), so it was crashing because it was overwriting the task structure (which generally causes Bad Things to happen that may involve wedging the system hard enough that control-C/Reboot will not reboot it). My solution was to give the task monitor more space to store task info in (2048 bytes rather than the 320 bytes previously, which may be adjusted prior to starting the task monitor with monitor::monitor-dict-space!.

I am making a new release, 1.3.3.3, to address this and some other bugs I found in task::dump-tasks, which is used by the task monitor, right now.

I've put out release 1.3.3.3, which should fix this issue.

It does, thanks!