Rooba
/
mitogen
mirror of https://github.com/mitogen-hq/mitogen.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
mitogen/examples/playbook/issue_113.yml

21 lines
419 B
YAML
Raw Normal View History

importer: avoid duplicate module load(!); closes #113. Amazed this one managed to scrape through for so long. Calling __import__ from within find_module() was causing the target module, in this case cookielib, to be loaded *then overwritten* by a subsequent duplicate load higher in the stack. The result is that cookielib was loaded twice, and, per usual Python import semantics, a reference to the partially initialized first cookielib was installed in sys.modules while its code executed. At the end of cookielib on 2.x, it imports _LWPCookieJar, which in turn imports the partially built cookielib from sys.modules, then subclasses the CookieJar from /that/ module. Everything is wonderful. Then the call returns back up into the import mechanism which restarts the entire process -- only this time, _LWPCookieJar is /not/ reinitialized, so the copy in sys.modules is still left with types pointing at the old module! So the duplicate import creates a new CookieJar which is not the base class of LWPCookieJar. Tada! 3 hours debugging. This is probably a performance fix in disguise, didn't realize things were so broken. It may also be a regression elsewhere. Urgently need to finish the tests.
2018-03-08 00:33:01 +00:00
---
issue #113: import crash reproduction
2018-03-07 14:42:14 +00:00
- hosts: all
importer: avoid duplicate module load(!); closes #113. Amazed this one managed to scrape through for so long. Calling __import__ from within find_module() was causing the target module, in this case cookielib, to be loaded *then overwritten* by a subsequent duplicate load higher in the stack. The result is that cookielib was loaded twice, and, per usual Python import semantics, a reference to the partially initialized first cookielib was installed in sys.modules while its code executed. At the end of cookielib on 2.x, it imports _LWPCookieJar, which in turn imports the partially built cookielib from sys.modules, then subclasses the CookieJar from /that/ module. Everything is wonderful. Then the call returns back up into the import mechanism which restarts the entire process -- only this time, _LWPCookieJar is /not/ reinitialized, so the copy in sys.modules is still left with types pointing at the old module! So the duplicate import creates a new CookieJar which is not the base class of LWPCookieJar. Tada! 3 hours debugging. This is probably a performance fix in disguise, didn't realize things were so broken. It may also be a regression elsewhere. Urgently need to finish the tests.
2018-03-08 00:33:01 +00:00
gather_facts: false
issue #113: import crash reproduction
2018-03-07 14:42:14 +00:00
tasks:
importer: avoid duplicate module load(!); closes #113. Amazed this one managed to scrape through for so long. Calling __import__ from within find_module() was causing the target module, in this case cookielib, to be loaded *then overwritten* by a subsequent duplicate load higher in the stack. The result is that cookielib was loaded twice, and, per usual Python import semantics, a reference to the partially initialized first cookielib was installed in sys.modules while its code executed. At the end of cookielib on 2.x, it imports _LWPCookieJar, which in turn imports the partially built cookielib from sys.modules, then subclasses the CookieJar from /that/ module. Everything is wonderful. Then the call returns back up into the import mechanism which restarts the entire process -- only this time, _LWPCookieJar is /not/ reinitialized, so the copy in sys.modules is still left with types pointing at the old module! So the duplicate import creates a new CookieJar which is not the base class of LWPCookieJar. Tada! 3 hours debugging. This is probably a performance fix in disguise, didn't realize things were so broken. It may also be a regression elsewhere. Urgently need to finish the tests.
2018-03-08 00:33:01 +00:00
issue #113: import crash reproduction
2018-03-07 14:42:14 +00:00
- name: Get auth token
uri:
url: "https://httpbin.org/post"
method: POST
body: "client_id=admin-cli&username=admin&\
password=keycloak_admin_password&grant_type=password"
return_content: true
validate_certs: false
register: r_token
no_log: false
run_once: true
importer: avoid duplicate module load(!); closes #113. Amazed this one managed to scrape through for so long. Calling __import__ from within find_module() was causing the target module, in this case cookielib, to be loaded *then overwritten* by a subsequent duplicate load higher in the stack. The result is that cookielib was loaded twice, and, per usual Python import semantics, a reference to the partially initialized first cookielib was installed in sys.modules while its code executed. At the end of cookielib on 2.x, it imports _LWPCookieJar, which in turn imports the partially built cookielib from sys.modules, then subclasses the CookieJar from /that/ module. Everything is wonderful. Then the call returns back up into the import mechanism which restarts the entire process -- only this time, _LWPCookieJar is /not/ reinitialized, so the copy in sys.modules is still left with types pointing at the old module! So the duplicate import creates a new CookieJar which is not the base class of LWPCookieJar. Tada! 3 hours debugging. This is probably a performance fix in disguise, didn't realize things were so broken. It may also be a regression elsewhere. Urgently need to finish the tests.
2018-03-08 00:33:01 +00:00
- assert:
Minor cleanup.
2018-03-08 00:49:54 +00:00
that: r_token.status == 200