otp
otp copied to clipboard
changes to fix erlang hung issue on IPv6 setup
Fixing problem in inet_drv.c where code is crashing due to infinite loop while searching interfaces Also updated code to avoid use of uninitialised pointer and updated macro to set variable to NULL after free.
For more details refer rabbitMQ thread: https://groups.google.com/g/rabbitmq-users/c/FJgf_Pp1O4c?pli=1
CT Test Results
3 files 125 suites 37m 24s :stopwatch: 1 449 tests 1 407 :heavy_check_mark: 42 :zzz: 0 :x: 1 748 runs 1 689 :heavy_check_mark: 59 :zzz: 0 :x:
Results for commit b54f5040.
:recycle: This comment has been updated with latest results.
To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.
See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.
Artifacts
// Erlang/OTP Github Action Bot
Looks good. The only thing we did not like was the changes to the FREE macro.
@bmk you should be able to push directly to the peculiar-pooja:ip_interface_fix
branch and revert the changes.
@bmk I actually changed macro to make sure that freed variable is always assigned to NULL, this will avoid dangling pointer issue.
Sorry for the delay. Yes, I/we got why the macro was changed. Its just that this macro is used everywhere, and this is rather basic behaviour (which now hides side effects). Anyway, I made a branch based on your branch and reverted the macro. When I compiled, I (the compiler actually) also found a missing '}', which I fixed. At the moment, we do not have a IPv6-only machine, so we cannot verify this...
And now I think I managed to push my updates to your branch...better late than never...
please let me know next step to merge this into master branch?
@peculiar-pooja - @bmk made this statement:
At the moment, we do not have a IPv6-only machine, so we cannot verify this...
Can you provide an IPv6-only server (a VM would be ideal), or instructions for how to create one?
The test would be to simply call the function and make sure it does not hang. And also returns the expected information. There is only one (1) explicit test case for this function (in the inet_SUITE), but it is used (as a utility) in several test suites. For the future it would of course be useful to have the instructions for how to create one (we tried, but could not figure out how to make it work), so please provide them!
Something I had forgotten: Depending on what version (of OTP) you are using, net:getifaddrs/0,1,2 might work.