-
Notifications
You must be signed in to change notification settings - Fork 530
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BBC: Blead Breaks Config::Model #18667
Comments
Not sure whether to comment here or at config-model, but I've started trying to look into this. (I tried running the test script with Investigating one of the SVs for which it reports "attempt to free unreferenced scalar", it appears that this is part of a hash that allows lookup by the numification of a Config::Model object:
@dod38fr's suggestion that this may be related to use of weakrefs looks quite likely at the moment. But the 67 module dependencies do make approaches such as bisection a challenge; I may have a go at bisecting manually later. |
There are only 'skip'ped commits left to test. I had a build failure on the first of those (440c185) which I don't understand - it wants
@richardleach do you have any clue how one of these commits could have caused an instability, possibly relating to weak refs? |
I guess this must be caused by corruption of |
@richardleach I can confirm that if I take blead@4e82c85b and replace the content of |
I managed to cut it down some; this is very clearly now a perl bug:
[Update] Unrolling the loop allows a slight further reduction:
Curiously, if the first two splices are combined into |
I won't have time to dig further for the next 24 hours or so, but with the reduced test case it should be relatively easy to diagnose now. |
@richardleach @tonycoz maybe one of you two could take a look? Ok, it appears the problem is that in In the test case (the updated, unrolled one above), the second call after
With the new extend_guts code, the first clear never happens, and we get:
.. and that now duplicate SV* is the one we end up double-freeing. It looks like when shifting the array contents the new code is correctly adjusting the number of elements to clear (
.. it crashes trying to build lib/buildcustomize.pl, so I guess it's not as simple as that. (I'm also confused why we check |
I've been trying to analyse the effects of the changes in 440c185 and 399fef9, but with little success. After some preamble, the core of the code is:
As far as I can see, the functionality of case 2 is correctly preserved through the changes. Case 3 differs by zeroing the newly allocated array even when not If nobody comes up with a better idea, I plan to revert those two commits to restore it to a working state. Optionally we could also then apply a minimal commit to replace each occurrence of |
@hvds - thanks for looking into this, I've very limited bandwidth at the moment but will try to take a look over the Easter weekend. |
Yes, I had also wondered why that was the case. IIRC, I queried it in the PR (#18072) for the changes above, but noone perked up with suggestions as to why that is as it is. So I left it as-is. |
Yes, looks like
Oh, one possibility: if the shift & unshift/push happens lots in a loop, extending it might reduce the number of times that av_extend() has to be called. |
I've created a new issue #18681 to consider this in more detail. It's mostly questions right now ... |
If someone can confirm that Config-Model-2.141 passes tests with some blead after ce9f3c9, this ticket can be closed. |
Linux
FreeBSD-12
LGTM. Closing ticket. |
DDUMONT/Config-Model-2.141.tar.gz fails on some systems since 5.33.5 or so.
Discussion happened so far in the CPAN module: dod38fr/config-model#26
but it's likely to be a bleadperl issue.
The text was updated successfully, but these errors were encountered: