Python uWSGI应用程序中的分段错误

我对在python脚本中使用uwsgi还相当陌生，所以希望这是一个幼稚的错误

我有两个不同的web应用程序，它们与独立但相关的python库进行交互，我们称它们为lib1.py和lib2.py

如果从命令行使用这些库，则不会出现错误

我创建了两个python文件app1.py和app2.py，它们分别连接到不同的uwsgi套接字。这些文件的基本框架是：

import lib1.py

#load objects into memory
MyObject = lib1.MyClass(init_params)

application(environ, start_response):
    status = '200 OK'

    output = MyObject.processRequest()

    response_headers = [('Content-type', 'text/html'),
                        ('Content-Length', str(len(output)))]

    start_response(status, response_headers)

    return [output]

导入lib2的app2.py也是如此

App1工作得很好，我对它的设置没有问题。当MyObject初始化时，它会加载几十个大型（100000多行，约100列）numpy数组，并将它们保存在内存中，以便应用程序函数在从web服务器接收请求时进行计算

App2尚未运行。。。lib2.py导入lib1.py，因为作为其工作的一部分，它需要在大型numpy数组上执行类似的计算。奇怪的是，它是抛出SEGFAULT的lib1.py函数之一。起初，我认为这可能是某种奇怪的双重导入的症状，这就是我第一次看到这种情况时将uwsgi分成两个独立的套接字和应用程序的原因。更奇怪的是，lib2只使用1个大的numpy数组，它比lib1最大的numpy数组小。通过在我的代码中放入大量的

print

语句并查看日志，我能够找到发生SEGFULT的确切线路：

inner_product_array = np.dot(self.coordinates, vector.T)

self.coordinates是一个2d MxN数组，vector.T是一个Nx1列向量。如果我这样限制self.coordinates数组，SEGFAULT就会消失：

self.coordinates[:500，：]

但是，每当切片变得比500大得多时，就会发生SEGFAULT，而这远远不是我需要的150000。同样，当self.coordinates可以达到50000x200时，此计算在lib1中不会引起任何问题

我觉得我已经尽可能地完成了，以确保没有模块/库被双重导入。其他numpy函数表现良好，而且，当从命令行使用时，lib2在处理大型数组时也能很好地工作

唯一需要提及的另一个奇怪症状是，以前，当我有一个app.py文件来处理我所有的uwsgi python代码，并使用PATH_INFO环境变量（包括除这两个变量之外的其他变量）处理不同应用程序的请求时，所有应用程序都可以正常工作，直到我添加了lib2。一旦添加了lib2，lib1就坏了，并开始给出SEGFAULTS。其他应用程序（不依赖于lib1或lib2）都很好

以下是日志中的错误：

*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 33866, cores: 1)
!!! uWSGI process 33866 got Segmentation Fault !!!
*** backtrace of 33866 ***
0   uwsgi                               0x00000001062f9420 uwsgi_backtrace + 48
1   uwsgi                               0x00000001062f9963 uwsgi_segfault + 51
2   libsystem_platform.dylib            0x00007fff9190ef1a _sigtramp + 26
3   multiarray.so                       0x0000000106fd4efe array_dealloc + 158
4   libBLAS.dylib                       0x00007fff908911ff rowMajorNoTranspose + 689
5   libBLAS.dylib                       0x00007fff9088f2c9 cblas_dgemv + 783
6   _dotblas.so                         0x00000001072e0129 dotblas_matrixproduct + 5513
7   libpython2.7.dylib                  0x00000001067d27c9 PyEval_EvalFrameEx + 14387
8   libpython2.7.dylib                  0x00000001067ced62 PyEval_EvalCodeEx + 1413
9   libpython2.7.dylib                  0x00000001067d557d _PyEval_SliceIndex + 757
10  libpython2.7.dylib                  0x00000001067d23e3 PyEval_EvalFrameEx + 13389
11  libpython2.7.dylib                  0x00000001067ced62 PyEval_EvalCodeEx + 1413
12  libpython2.7.dylib                  0x00000001067d557d _PyEval_SliceIndex + 757
13  libpython2.7.dylib                  0x00000001067d23e3 PyEval_EvalFrameEx + 13389
14  libpython2.7.dylib                  0x00000001067ced62 PyEval_EvalCodeEx + 1413
15  libpython2.7.dylib                  0x00000001067d557d _PyEval_SliceIndex + 757
16  libpython2.7.dylib                  0x00000001067d23e3 PyEval_EvalFrameEx + 13389
17  libpython2.7.dylib                  0x00000001067ced62 PyEval_EvalCodeEx + 1413
18  libpython2.7.dylib                  0x00000001067d557d _PyEval_SliceIndex + 757
19  libpython2.7.dylib                  0x00000001067d23e3 PyEval_EvalFrameEx + 13389
20  libpython2.7.dylib                  0x00000001067ced62 PyEval_EvalCodeEx + 1413
21  libpython2.7.dylib                  0x000000010677330a PyFunction_SetClosure + 826
22  libpython2.7.dylib                  0x00000001067552ac PyObject_Call + 99
23  libpython2.7.dylib                  0x00000001067d4d6b PyEval_CallObjectWithKeywords + 93
24  uwsgi                               0x0000000106314097 python_call + 23
25  uwsgi                               0x000000010631620f uwsgi_request_wsgi + 879
26  uwsgi                               0x00000001062ab530 wsgi_req_recv + 288
27  uwsgi                               0x00000001062f7205 simple_loop_run + 229
28  uwsgi                               0x00000001062fe577 uwsgi_ignition + 439
29  uwsgi                               0x00000001062fe363 uwsgi_worker_run + 835
30  uwsgi                               0x00000001062fbe7a uwsgi_run + 442
31  uwsgi                               0x00000001062f9b0e main + 14
32  libdyld.dylib                       0x00007fff854425c9 start + 1
*** end of backtrace ***

下面是我用于app2的uwsgi的xml配置：

<uwsgi>
    <socket>127.0.0.1:3033</socket>
    <chdir>/abs/path/to/site_folder/wsgi</chdir>
    <wsgi-file>/abs/path/to/site_folder/wsgi/app2.py</wsgi-file>
    <logto>/abs/path/to/logdir/app2.log</logto>
    <pidfile>app2.pid</pidfile>
    <enable-threads></enable-threads>
    <daemonize2></daemonize2>
</uwsgi>

127.0.0.1:3033
/abs/path/to/site\u文件夹/wsgi
/abs/path/to/site\u文件夹/wsgi/app2.py
/abs/path/to/logdir/app2.log
app2.pid

更新

我在AmazonLinuxEC-2服务器上创建了一个相同的设置，一切都正常工作。我遇到问题的本地机器是OSX。我仍然不明白为什么只有在uWSGI框架中才会发生这种情况，并且希望能够在本地进行开发和测试，但这似乎更像是一个安装问题（OpenBLAS？），而不是其他问题。你知道为什么uWSGI会在相同的数据和相同的函数调用中触发这种错误行为吗？作为一个无错误的命令行脚本和一个单独的无错误uWSGI应用程序