bpo-33615: avoid extra decref#7251
Conversation
vstinner
left a comment
There was a problem hiding this comment.
I approve blindly the PR just because any attempt to fix the annoying test failure is a good idea :-D Also, I trust Eric to understand his own code :-D
|
Hum, the change doesn't work yet... test_run_string_arg_resolved (test.test__xxsubinterpreters.ChannelTests) ... Fatal Python error: Objects/dictobject.c:557 object at 0x14dbb111ec48 has negative ref count -2604246222170760230 |
|
Oops sorry, I forgot to mention that the crash comes from Travis CI: |
|
Yeah, I've been working on this whenever I can spare some time. I haven't been able to reproduce the issue locally (something racy is happening) so I was planning to rely on the buildbots to verify when I've fixed the issue. I'm actually glad things failed on CI since it reduces the latency of results (vs. buildbots). :) The current PR is the first thing I've tried to fix the issue. Also, note that with clang the PR led to a refcount-related abort, whereas with GCC it segfaulted. I'd be much more likely to resolve this quickly if I could see a C-level backtrace on CI/buildbots (and moreso if I could repro locally), but I expect that isn't an option. :/ |
fe153c4 to
19a530c
Compare
19a530c to
ea22ea3
Compare
|
FYI, I'm running this against the custom buildbot builders before merging. |
|
The custom build looks good so I'm going to merge. |
For bpo-32604 I added extra subinterpreter-related tests (see #6914), which caused a few buildbots to fail. This patch ensures that refcounts in channels are handled properly.
WIP: I'll be iterating against the failing buildbots (particularly "x86 Gentoo Refleaks 3.x") until this is resolved. The problem may have already existed before #6914 (and only surfaced with the new tests). However, I'm going to start from #6914 and then dive deeper. My first stab at the problem involves preventing a race (albeit an unlikely one) in _PyObject_GetCrossInterpreterData().
https://bugs.python.org/issue33615