Time/NTP sometimes crashes in gethostbyname()
|Reported by:||ttcoder||Owned by:||nobody|
|Component:||Network & Internet||Version:||R1/Development|
This is hrev49523
We load Time as an add-on into CC's address space to use the Network Time Protocol syncing feature within it, about every 3 minutes (basically after each transition from one song to the next). Seems to work great initially.
However I Just saw this for the first time after doing an extended 12+ hr test run since the past night (and we had reports hinting at this for a few weeks in older hrevs).
All splitviews in Debugger were collapsed and 'locked' (I thought I had deleted the settings in config/settings/Debugger but will try again before filing a ticket for that) but retrieving the info from syslog was easy:
KERN: vm_soft_fault: va 0x719a0000 not covered by area in address space KERN: vm_page_fault: vm_soft_fault returned error 'Bad address' on fault at 0x719a0844, ip 0x143481c, write 0, user 1, thread 0x4562 KERN: vm_page_fault: thread "(add-on)ntp_update_time" (17762) in team "CommandCenter" (602) tried to read address 0x719a0844, ip 0x143481c ("libnetwork.so_seg0ro" +0x1781c) KERN: debug_server: Thread 17762 entered the debugger: Segment violation KERN: stack trace, current PC 0x143481c nsdispatch + 0xe4: KERN: (0x71945ff8) 0x142f811 gethostbyname_internal + 0x305 KERN: (0x71946048) 0x142f4a9 gethostbyname + 0x79 KERN: (0x71946078) 0x5cf11c ntp_update_time__FPCcPPCcPl + 0x24 KERN: (0x71946188) 0x1903f04 thread_func__25NetworktimeprefletAsAddonPv + 0x290 KERN: (0x719462b8) 0x20d3c7f thread_entry + 0x23
FWIW -- might be just a coincidence, but it ran fine when unattended through the night but crashed within a few minutes of me checking the system this morning -- I checked if CC was running fine, launched a browser, accessed sites.
Will shortly provide some sample code to make it easier to reproduce this (maybe combined with some heavier network and DNS access usage, in case there is a concurrency component involved in the bug?)
Change History (22)
by , 3 years ago
by , 3 years ago