Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This patch accounts for zw_map_view_of_section() returning
NT_STATUS_CONFLICTING_ADDRESSES (0xC0000018) due to third-party
software thread creation upon process initialization. The conflict
occurs when the address of the stack that is allocated for the
third-party thread happens to coincide with the internal section
address which was derived from the parent. As should be noted, and
while we could decide to always reset ctx->section_addr prior to
mapping the internal section, the advantage of the current solution
(when acocmpanied by the wrapping calls to __ntapi_log_write)
consists in the indication as to whether third-party thread creation
had interfered with internal process initialization routines.
|
|
|
|
|
|
Following this change, the temporary internal client thread is created
only after the daemon dedicated thread has signaled the daemon-is-ready
event.
|
|
|
|
|
|
|
|
|
|
Integration of this function into the library has been delayed
since the AFD ioctl operation, while succeeding, seems to only
memset the caller's address buffer, and accordingly to never
copy the remote socket address to it. Callers of sc_getpeername()
should therefore first check the return value for success -- which
may be used as indication that the socket is connected -- and then
test the returned address buffer for validity.
|
|
|
|
|
|
|
|
|