libuv: Failed test process_title_threadsafe
- Version: v1.x
- Platform: AIX, OS X
Reported earlier in #2041, seem to be failing in OS X too. Opening here to detach from #2041 that addressed a different issue from this one
not ok 182 - process_title_threadsafe
# exit code 393222
# Output from process `process_title_threadsafe`:
# Assertion failed in test/test-process-title-threadsafe.c on line 50: 0 == strcmp(buffer, titles[0]) || 0 == strcmp(buffer, titles[1]) || 0 == strcmp(buffer, titles[2]) || 0 == strcmp(buffer, titles[3])
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 15 (15 by maintainers)
I guess now I know what is happening. So @richardlau, your original question seem to be valid, and very much relevant to the issue. This is the sequence I figured out that led to this one byte corruption:
so many
uv_set_process_titleanduv_get_process_titleare being called, with the former on many threads, and the later on the main.modification as well as retrieval of the title string is carried out under the cover of a mutex
the title string itself is a static non-local variable for persistence across calls.
in
uv_get_process_titlewe calculate the length of the title string before entering the mutex. In the problematic scenario, this can cause:and hence this result.
test case remains in tact, and a comprehensive fix IMO should be:
Ran a 2K times and did not see any failure. I will raise a PR for this, but would appreciate if someone agrees to my theory.
@gireeshpunathil Maybe also print
len?len == 0would cause the memcpy not to copy anything.that may be rac-y, but given all the titles are of equal length (in this case), that does not look to be a problem source - for example, whether we got the length of the previous title or the next tile, it is always going to be the same.