Conversation
assumption is that, worst case, for platform that don't support it, it will have no impact
|
FWIW, Meson actually generates a totally random number for you with the python code: This is also relatively easy to do in a bash shell (due to the presence of $RANDOM) but I'm not sure how to do it with a generic /bin/sh... |
|
Extended tests seem to show that failures are still possible. |
|
I tried this branch, and got the following results: https://github.com/mesonbuild/wrapdb/runs/6216706988?check_suite_focus=true It didn't get as far as the tests. |
|
Strange, this PR should have no impact on such kind of linking error... |
|
I haven't tried the dev branch, only the latest release and then this PR branch. So it could be a preexisting issue. All I know is I can't currently compile this PR to test it. I agree that it doesn't seem like calloc/malloc should affect whether pthread is linkable... |
|
Alright, I tried the dev branch at https://github.com/mesonbuild/wrapdb/runs/6216706988?check_suite_focus=true It is still broken there too. Looking around a bit, I think this goes back to the issue in #2976 |
|
Ideally, we should have a |
|
This PR when applied to the latest dev branch compiles correctly, but zstreamtest still dies of SIGinvalid. Github Actions log: https://github.com/mesonbuild/wrapdb/runs/6632846325?check_suite_focus=true |
|
The first part of the PR, replacing |
fix segfault error identified by @eli-schwartz when running
zstreamtestwithMALLOC_PERTURB_.The quicker solution is to use
callocinstead ofmallocto ensure proper initialization.I don't anticipate any speed impact, as these memory segments are relatively small.
On the other hand,
callocis bound to result in safer initialization.Tested using
MALLOC_PERTURB_=124, as in #3119. No failure after this patch.