exception error in _scproxy.so when called after fork #58037
Comments
|
Get this error when trying to run Moviegrabber on a mac running v2.7. Crash report below. Process: Python [2444] Date/Time: 2011-12-21 20:32:41.233 -0500 Interval Since Last Report: 357638 sec Crashed Thread: 0 Exception Type: EXC_BAD_ACCESS (SIGSEGV) VM Regions Near 0x108: Application Specific Information: Thread 0 Crashed: Thread 0 crashed with X86 Thread State (64-bit): Binary Images: External Modification Summary: VM Region Summary: REGION TYPE VIRTUAL Model: Macmini3,1, BootROM MM31.0081.B06, 2 processors, Intel Core 2 Duo, 2 GHz, 4 GB, SMC 1.35f0 |
Dankamp
mannequin
added
the
type-crash
|
Can you isolate the cause? There is way too much in that core dump to try to debug the problem. Without knowing what code in this Moviegrabber app caused the bug we can't do anything to debug the issue. |
|
On Jan 20, 2012, at 4:20 PM, Brett Cannon wrote:
All I know is that this happens with Moviegrabber and no other app that I am running (5 of them). Attached is the code I am using. This is WAY above what I know how to do but I can tell you that I am running it on a mac with 2.7.1 installed and OSX lion. Attached is the source. Thanks |
|
Then I'm going to assume the bug lies with Moviegrabber doing something wrong and it isn't Python's direct fault. |
|
I have received this from the macpython listserv it that helps. Would really like to find this issue. From the traceback, it appears that there is a problem with Python's On Jan 21, 2012, at 12:03 PM, Brett Cannon wrote:
|
|
The problem was originally discussed in these threads: http://mail.python.org/pipermail/pythonmac-sig/2011-December/023428.html Because _scproxy is used to get information about Internet proxies, a test case should be constructed on OS X 10.7.x with a proxy configured. |
|
I've once again reviewed the _scproxy code and that code seems correct (although that doesn't say too much for subtle bugs because I wrote the initial version of the module). Dan: is it possible to tell moviegrabber to use another python installation (in particular /Library/Frameworks/Python.framework)? If so, is the problem reproducable with the latest binaries on www.python.org? The crash report says that the actual crash occurs inside a function called by SCDynamicStoreCopyProxies and I wouldn't know how Python's use of that function is wrong. The crash could still be caused by the way the moviegrabber application uses python, but I'd consider that a bug in moviegrabber unless there is a clear indication of a bug in python itself. BTW. Is Moviegrabber this software? : http://sourceforge.net/projects/moviegrabber/ |
|
If it is the moviegrabber I linked to: that's a 100% python script using some other opensource libraries. It does use multiprocessing, and that might mean this is the same problem as bpo-9405. That issue should be fixed in the repository (for a long time, the issue is not yet closed because I wanted to write a test case). |
|
FWIW, I've run into the same issue in a homegrown application with 2.6.8, 2.7.2 and 2.7.3 (these were the only versions I've tested). Looking around a little bit, I suspect this might be a bug in SCDynamicStoreCopyProxies that's only present on OS X 10.7 and only triggered when invoked in a forked child (?) [1][2]. I've tried working around it by invoking SCDynamicStoreCopyProxies with a non-NULL SCDynamicStoreRef but to no avail. Since I don't need this Python application to use HTTP proxies, I'm working around it now like this: proxy_handler = urllib2.ProxyHandler({})
opener = urllib2.build_opener(proxy_handler)
request = urllib2.Request(...)
response = opener.open(request)[1] http://forums.macrumors.com/archive/index.php/t-1295113.html |
|
Sigh... The crash is a subprocess started with fork is not entirely unexpected, although I had hoped that the current version of _scproxy would be safe enough. A number of Apple frameworks detect that a process called fork after they initialized and then explictly crash (basicly a call to abort()). In this case it appears to just not work correctly. I'm not sure how to fix this, other than spawning a small helper program to query the proxy settings. That could get prohibitively expensive when fetching a lot of URLs though (and an RPC system might run into the a similar problem after calling fork...) |
|
Closed as an out of date issue. |
|
Why is it out of date? Has it been fixed? Has apple changed their abort policy? Obviously it isn't high priority, though :) |
bitdancer
changed the title
|
This is effectively the same as bpo-27126. The discussion there convinced me that this may not be working around, since it isn't the only place this can happen! This same crash, caused by libdispatch not being fork compatible, also happens with sqlite and tk. We can probably add a workaround specifically for _scproxy.so, but those others would still cause the crash. |
|
I have run into this bug which can be reliably reproduced by importing tkinter. However, I have found another workaround if one does not want to deal with the environmental variable and may point to a possible bug fix. Before forking, any use of Example works under Python 3.6.4 and Mac OS 10.12.6 |
|
Still present in python 3.8 and bpo-38658. Another workaround is in https://bugs.python.org/issue30385#msg293958 |
|
I propose closing this as 3th-party or out-of-date:
|
Done. |
|
I'll bet it's a symptom of fork-without-exec that I wrote about 3 years ago. If so, it is not fixable in Python. |
It is. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: