#12319: Time/NTP sometimes crashes in gethostbyname()
--------------------------------+------------------------------
Reporter: ttcoder | Owner: nobody
Type: bug | Status: new
Priority: normal | Milestone: R1/beta1
Component: Network & Internet | Version: R1/Development
Keywords: | Blocked By:
Blocking: | Has a Patch: 0
Platform: All |
--------------------------------+------------------------------
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?)
--
Ticket URL: <https://dev.haiku-os.org/ticket/12319>
Haiku <https://dev.haiku-os.org>
Haiku - the operating system.
