Bug 14373 - socket_wrapper torture_teardown_echo_srv truncates pids to 16-bits
Summary: socket_wrapper torture_teardown_echo_srv truncates pids to 16-bits
Status: RESOLVED FIXED
Alias: None
Product: cwrap
Classification: Unclassified
Component: library (show other bugs)
Version: unspecified
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Andreas Schneider
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-08 03:52 UTC by Mike Gilbert
Modified: 2021-02-16 17:17 UTC (History)
0 users

See Also:


Attachments
patch (1.20 KB, patch)
2020-05-08 03:52 UTC, Mike Gilbert
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gilbert 2020-05-08 03:52:42 UTC
Created attachment 15959 [details]
patch

When I run the unit tests for socket_wrapper, a bunch of echo_srv processes are left running in the background.

The torture_teardown_echo_srv function reads a PID value from a file, and truncates the value to 16-bits before passing it to the kill() function.

On Linux, pid_t is a 32-bit type. On my system, /proc/sys/kernel/pid_max is set to 4194304. This means the kernel will generate PID values larger than the maximum 16-bit value (65535).

Attached is a patch to avoid truncating the PID values.

This does remove the bounds checking from the code. However, figuring out the maximum value a pid_t can hold in a portable way is a bit ugly. The input data is under our control anyway, so I am choosing to ignore the possibility of an over-sized PID in the pidfile.
Comment 1 Andreas Schneider 2020-05-08 08:55:55 UTC
Thank you very much for the bug report and patch!

Could you please create a Merge Request at: https://gitlab.com/cwrap/socket_wrapper
Comment 2 Mike Gilbert 2020-05-08 13:55:39 UTC
(In reply to Andreas Schneider from comment #1)

Done.
Comment 3 Andreas Schneider 2020-05-16 18:06:13 UTC
This has been fixed upstream.

Thank you very much for your contribution!
Comment 4 Stefan Metzmacher 2021-02-16 16:29:08 UTC
(In reply to Andreas Schneider from comment #3)
Can we close this bug?