Python doppelfreier Fehler für große Datenmengen

Habe ich ein sehr einfaches Skript in Python, aber aus irgendeinem Grund bekomme ich die folgende Fehlermeldung beim ausführen einer großen Menge von Daten:

*** glibc detected *** python: double free or corruption (out): 0x00002af5a00cc010 ***

Bin ich verwendet, um diese Fehler bis kommenden in C oder C++, wenn man versucht, Speicher freizugeben, der bereits freigegeben wurde. Jedoch, durch mein Verständnis von Python (und vor allem so, wie ich geschrieben habe, der code), ich verstehe wirklich nicht, warum dies passieren sollte.

Hier ist der code:

#!/usr/bin/python -tt                                                                                                                                                                                                                         

import sys, commands, string
import numpy as np
import scipy.io as io
from time import clock

W = io.loadmat(sys.argv[1])['W']
size = W.shape[0]
numlabels = int(sys.argv[2])
Q = np.zeros((size, numlabels), dtype=np.double)
P = np.zeros((size, numlabels), dtype=np.double)
Q += 1.0 / Q.shape[1]
nu = 0.001
mu = 0.01
start = clock()
mat = -nu + mu*(W*(np.log(Q)-1))
end = clock()
print >> sys.stderr, "Time taken to compute matrix: %.2f seconds"%(end-start)

Darf man Fragen, warum deklarieren Sie ein P und ein Q numpy-array? Ich habe einfach das tun, entsprechend den tatsächlichen Bedingungen (wie dieser code ist einfach nur ein segment dessen, was ich tatsächlich tun, wo brauche ich eine P-matrix und deklarieren Sie es vorher).

Ich habe Zugang zu einer 192GB Maschine, und so getestet habe ich dieses heraus auf einer sehr großen SciPy sparse matrix (2,2 Millionen um 2,2 Millionen, aber sehr spärlich, das ist nicht das Problem). Der Hauptspeicher wird durch die Q -, P -, und mat Matrizen, wie Sie alle sind 2,2 Millionen bis zum Jahr 2000 Matrizen (Größe = 2,2 Millionen numlabels = 2000). Die peak-Speicher geht bis zu 131GB, die passt bequem in Erinnerung. Während die matrix mat berechnet, bekomme ich die glibc Fehler, und mein Prozess geht automatisch in den sleep - (S) - Zustand, ohne freigeben der 131GB hat es gedauert, bis.

Angesichts der bizarren (für Python) Fehler (ich bin nicht explizit freigeben von nichts) und die Tatsache, dass dies funktioniert gut für kleinere matrixgrößen (rund 1,5 Millionen Euro von 2000), ich bin wirklich nicht sicher, wo Sie anfangen zu Debuggen.

Als Ausgangspunkt habe ich die Einstellung "ulimit -s unlimited", bevor Sie ausgeführt, aber ohne Erfolg.

Jede Hilfe oder Einsicht in numpy das Verhalten mit großen Datenmengen zu begrüßen wäre.

Beachten Sie, dass dies NICHT ein " out of memory Fehler - ich habe 196GB, und mein Prozess erreicht etwa 131GB und bleibt dort für einige Zeit, bevor er den Fehler unten.

Update: Februar 16, 2013 (1:10 PM PST):

Als pro-Vorschläge, lief ich Python mit GDB. Interessanterweise auf der einen GDB laufen habe ich vergessen zum einstellen der stack-Größe, die Begrenzung auf "unbegrenzt", und bekam folgende Ausgabe:

*** glibc detected *** /usr/bin/python: munmap_chunk(): invalid pointer: 0x00007fe7508a9010 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x733b6)[0x7ffff6ec23b6]
/usr/lib64/python2.7/site-packages/numpy/core/multiarray.so(+0x4a496)[0x7ffff69fc496]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4e67)[0x7ffff7af48c7]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x309)[0x7ffff7af6c49]
/usr/lib64/libpython2.7.so.1.0(PyEval_EvalCode+0x32)[0x7ffff7b25592]
/usr/lib64/libpython2.7.so.1.0(+0xfcc61)[0x7ffff7b33c61]
/usr/lib64/libpython2.7.so.1.0(PyRun_FileExFlags+0x84)[0x7ffff7b34074]
/usr/lib64/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0x189)[0x7ffff7b347c9]
/usr/lib64/libpython2.7.so.1.0(Py_Main+0x36c)[0x7ffff7b3e1bc]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x7ffff6e6dbfd]
/usr/bin/python[0x4006e9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 09:01 50336181                           /usr/bin/python2.7
00600000-00601000 r--p 00000000 09:01 50336181                           /usr/bin/python2.7
00601000-00602000 rw-p 00001000 09:01 50336181                           /usr/bin/python2.7
00602000-00e5f000 rw-p 00000000 00:00 0                                  [heap]
7fdf2584c000-7ffff0a66000 rw-p 00000000 00:00 0 
7ffff0a66000-7ffff0a6b000 r-xp 00000000 09:01 50333916                   /usr/lib64/python2.7/lib-dynload/mmap.so
7ffff0a6b000-7ffff0c6a000 ---p 00005000 09:01 50333916                   /usr/lib64/python2.7/lib-dynload/mmap.so
7ffff0c6a000-7ffff0c6b000 r--p 00004000 09:01 50333916                   /usr/lib64/python2.7/lib-dynload/mmap.so
7ffff0c6b000-7ffff0c6c000 rw-p 00005000 09:01 50333916                   /usr/lib64/python2.7/lib-dynload/mmap.so
7ffff0c6c000-7ffff0c77000 r-xp 00000000 00:12 54138483                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/streams.so
7ffff0c77000-7ffff0e76000 ---p 0000b000 00:12 54138483                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/streams.so
7ffff0e76000-7ffff0e77000 r--p 0000a000 00:12 54138483                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/streams.so
7ffff0e77000-7ffff0e78000 rw-p 0000b000 00:12 54138483                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/streams.so
7ffff0e78000-7ffff0e79000 rw-p 00000000 00:00 0 
7ffff0e79000-7ffff0e9b000 r-xp 00000000 00:12 54138481                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5_utils.so
7ffff0e9b000-7ffff109a000 ---p 00022000 00:12 54138481                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5_utils.so
7ffff109a000-7ffff109b000 r--p 00021000 00:12 54138481                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5_utils.so
7ffff109b000-7ffff109f000 rw-p 00022000 00:12 54138481                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio5_utils.so
7ffff109f000-7ffff10a0000 rw-p 00000000 00:00 0 
7ffff10a0000-7ffff10a5000 r-xp 00000000 09:01 50333895                   /usr/lib64/python2.7/lib-dynload/zlib.so
7ffff10a5000-7ffff12a4000 ---p 00005000 09:01 50333895                   /usr/lib64/python2.7/lib-dynload/zlib.so
7ffff12a4000-7ffff12a5000 r--p 00004000 09:01 50333895                   /usr/lib64/python2.7/lib-dynload/zlib.so
7ffff12a5000-7ffff12a7000 rw-p 00005000 09:01 50333895                   /usr/lib64/python2.7/lib-dynload/zlib.so
7ffff12a7000-7ffff12ad000 r-xp 00000000 00:12 54138491                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio_utils.so
7ffff12ad000-7ffff14ac000 ---p 00006000 00:12 54138491                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio_utils.so
7ffff14ac000-7ffff14ad000 r--p 00005000 00:12 54138491                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio_utils.so
7ffff14ad000-7ffff14ae000 rw-p 00006000 00:12 54138491                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/io/matlab/mio_utils.so
7ffff14ae000-7ffff14b5000 r-xp 00000000 00:12 54138562                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_csgraph.so
7ffff14b5000-7ffff16b4000 ---p 00007000 00:12 54138562                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_csgraph.so
7ffff16b4000-7ffff16b5000 r--p 00006000 00:12 54138562                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_csgraph.so
7ffff16b5000-7ffff16b6000 rw-p 00007000 00:12 54138562                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_csgraph.so
7ffff16b6000-7ffff17c2000 r-xp 00000000 00:12 54138558                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_bsr.so
7ffff17c2000-7ffff19c2000 ---p 0010c000 00:12 54138558                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_bsr.so
7ffff19c2000-7ffff19c3000 r--p 0010c000 00:12 54138558                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_bsr.so
7ffff19c3000-7ffff19c6000 rw-p 0010d000 00:12 54138558                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_bsr.so
7ffff19c6000-7ffff19d5000 r-xp 00000000 00:12 54138561                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_dia.so
7ffff19d5000-7ffff1bd4000 ---p 0000f000 00:12 54138561                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_dia.so
7ffff1bd4000-7ffff1bd5000 r--p 0000e000 00:12 54138561                   /home/avneesh/.local/lib/python2.7/site-packages/scipy/sparse/sparsetools/_dia.so
Program received signal SIGABRT, Aborted.
0x00007ffff6e81ab5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6e81ab5 in raise () from /lib64/libc.so.6
#1  0x00007ffff6e82fb6 in abort () from /lib64/libc.so.6
#2  0x00007ffff6ebcdd3 in __libc_message () from /lib64/libc.so.6
#3  0x00007ffff6ec23b6 in malloc_printerr () from /lib64/libc.so.6
#4  0x00007ffff69fc496 in ?? () from /usr/lib64/python2.7/site-packages/numpy/core/multiarray.so
#5  0x00007ffff7af48c7 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#6  0x00007ffff7af6c49 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#7  0x00007ffff7b25592 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#8  0x00007ffff7b33c61 in ?? () from /usr/lib64/libpython2.7.so.1.0
#9  0x00007ffff7b34074 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#10 0x00007ffff7b347c9 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#11 0x00007ffff7b3e1bc in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#12 0x00007ffff6e6dbfd in __libc_start_main () from /lib64/libc.so.6
#13 0x00000000004006e9 in _start ()

Wenn ich die stack-Größe auf unlimitiert", bekomme ich die folgende:

*** glibc detected *** /usr/bin/python: double free or corruption (out): 0x00002abb2732c010 ***
^X^C
Program received signal SIGINT, Interrupt.
0x00002aaaab9d08fe in __lll_lock_wait_private () from /lib64/libc.so.6
(gdb) bt
#0  0x00002aaaab9d08fe in __lll_lock_wait_private () from /lib64/libc.so.6
#1  0x00002aaaab969f2e in _L_lock_9927 () from /lib64/libc.so.6
#2  0x00002aaaab9682d1 in free () from /lib64/libc.so.6
#3  0x00002aaaaaabbfe2 in _dl_scope_free () from /lib64/ld-linux-x86-64.so.2
#4  0x00002aaaaaab70a4 in _dl_map_object_deps () from /lib64/ld-linux-x86-64.so.2
#5  0x00002aaaaaabcaa0 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2
#6  0x00002aaaaaab85f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#7  0x00002aaaaaabc5da in _dl_open () from /lib64/ld-linux-x86-64.so.2
#8  0x00002aaaab9fb530 in do_dlopen () from /lib64/libc.so.6
#9  0x00002aaaaaab85f6 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2
#10 0x00002aaaab9fb5cf in dlerror_run () from /lib64/libc.so.6
#11 0x00002aaaab9fb637 in __libc_dlopen_mode () from /lib64/libc.so.6
#12 0x00002aaaab9d60c5 in init () from /lib64/libc.so.6
#13 0x00002aaaab080933 in pthread_once () from /lib64/libpthread.so.0
#14 0x00002aaaab9d61bc in backtrace () from /lib64/libc.so.6
#15 0x00002aaaab95dde7 in __libc_message () from /lib64/libc.so.6
#16 0x00002aaaab9633b6 in malloc_printerr () from /lib64/libc.so.6
#17 0x00002aaaab9682dc in free () from /lib64/libc.so.6
#18 0x00002aaaabef1496 in ?? () from /usr/lib64/python2.7/site-packages/numpy/core/multiarray.so
#19 0x00002aaaaad888c7 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.7.so.1.0
#20 0x00002aaaaad8ac49 in PyEval_EvalCodeEx () from /usr/lib64/libpython2.7.so.1.0
#21 0x00002aaaaadb9592 in PyEval_EvalCode () from /usr/lib64/libpython2.7.so.1.0
#22 0x00002aaaaadc7c61 in ?? () from /usr/lib64/libpython2.7.so.1.0
#23 0x00002aaaaadc8074 in PyRun_FileExFlags () from /usr/lib64/libpython2.7.so.1.0
#24 0x00002aaaaadc87c9 in PyRun_SimpleFileExFlags () from /usr/lib64/libpython2.7.so.1.0
#25 0x00002aaaaadd21bc in Py_Main () from /usr/lib64/libpython2.7.so.1.0
#26 0x00002aaaab90ebfd in __libc_start_main () from /lib64/libc.so.6
#27 0x00000000004006e9 in _start ()

Dies lässt mich glauben, dass das grundlegende Problem mit dem numpy multiarray-core-Modul (Linie #4 in der ersten Ausgabe und der Linie #18 im zweiten). Ich bringe es als bug-report in beiden numpy und scipy nur für den Fall.

Hat jemand das schon mal gesehen?

Update: Februar 17, 2013 (4:45 PM PST)

Ich eine Maschine gefunden, die ich laufen konnte den code auf, das eine neuere version von SciPy (0.11) und NumPy (1.7.0). Die Ausführung des Codes straight up (ohne GDB) führte zu einem seg-fault, ohne irgendeine Ausgabe auf stdout oder stderr. Läuft wieder durch GDB, bekomme ich die folgende:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabead970 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00002aaaabead970 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00002aaaac5fcd04 in PyDataMem_FREE (ptr=<optimized out>, $K8=<optimized out>) at numpy/core/src/multiarray/multiarraymodule.c:3510
#2  array_dealloc (self=0xc00ab7edbfc228fe) at numpy/core/src/multiarray/arrayobject.c:416
#3  0x0000000000498eac in PyEval_EvalFrameEx ()
#4  0x000000000049f1c0 in PyEval_EvalCodeEx ()
#5  0x00000000004a9081 in PyRun_FileExFlags ()
#6  0x00000000004a9311 in PyRun_SimpleFileExFlags ()
#7  0x00000000004aa8bd in Py_Main ()
#8  0x00002aaaabe4f76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#9  0x000000000041b9b1 in _start ()

Ich verstehe, das ist nicht so nützlich, wie ein NumPy kompiliert mit debug-Symbolen, werde ich versuchen, das zu machen und poste die Ausgabe später.

Kommentar zu dem Problem - Öffnen
Interessant-Obwohl, könnten Sie besser dran, die Einreichung einer bug-Meldung mit scipy. Vielleicht kompilieren mit -g unter gdb wäre auch hilfreich-zumindest dann könnte man sehen, wo war der code, wenn der Fehler passiert ist... Kommentarautor: mgilson
Was Python/numpy-version verwenden Sie? Ich sehe einige bug-reports, aber Sie sind alt und schlage vor, das problem ist jetzt behoben. Kommentarautor: BrenBarn
Auch, wenn ich mich nicht Irre, Numpy 1.5.1 ist ziemlich weit out-of-date (mehr als zwei Jahre alt). Haben Sie versucht, aktualisieren Numpy? Kommentarautor: nneonneo
Das ist ein bug (wahrscheinlich in einer C-Erweiterung). Jedoch, der Ort, wo es auftauchte, ist in der Regel nicht der Ort, der ihn brach, sondern viel später (so der backtrace zeigt, wo der Fehler schließlich erkannt wurde und nicht, wo es gemacht wurde). Versuchen valgrind --tool=memcheck python xxx.py um herauszufinden, wo genau es ist. Kommentarautor: Danny Milosavljevic
Ich glaube mich zu erinnern ein glibc-problem mit mehr als 131072 MB (0x2000000000 bytes) von heap. Der gleiche Fehler aufgetaucht, in Xen-heap-Größe-Berechnungen, vor Ewigkeiten. Gegeben, dass Sie Ihren peak-Auslastung ist "131 GB", es könnte unter Umständen damit zusammenhängen. Was passiert mit etwas größer - Matrizen? Sie werden Abstürzen, aber ist das noch passieren, bei 131 GB, oder höher? Wenn es eine Grenze von 128 GiB, könnte es nicht ein Fehler von numpy überhaupt. Kommentarautor: LSerni

InformationsquelleAutor der Frage Avneesh | 2013-02-16

  1. 5

    Nachdem die Diskussionen über das gleiche Problem auf der Numpy Github Seite (https://github.com/numpy/numpy/issues/2995) es hat gewesen gebracht zu meiner Aufmerksamkeit, dass Numpy/Scipy nicht die Unterstützung einer so großen Anzahl der nicht-Nullen in der resultierenden sparse-matrix.

    Grundsätzlich W ist eine sparse-matrix, und Q (oder np.log(Q)-1) ist eine Dichte matrix. Bei der Multiplikation einer dichten matrix mit einem lichten, das resultierende Produkt wird auch vertreten sein in sparse-matrix-form (was viel Sinn macht). Beachten Sie jedoch, dass, da habe ich keine null-Zeilen in meiner W matrix, das resultierende Produkt W*(np.log(Q)-1) haben nnz > 2^31 (2,2 Millionen multipliziert mit 2000) und dies überschreitet die maximale Anzahl der Elemente in einer sparse-matrix in den aktuellen Versionen von Scipy.

    In dieser Phase, ich bin mir nicht sicher wie sonst zu bekommen dies funktioniert, abgesehen von einer re-Implementierung in einer anderen Sprache. Vielleicht kann es noch getan werden in Python, aber es könnte besser sein, nur schreiben Sie eine C++ - und Eigen-Implementierung.

    Einen besonderen Dank an pv. helfen, diese zu lokalisieren das genaue Problem, und danke an alle anderen für das brainstorming!

    InformationsquelleAutor der Antwort Avneesh

  2. 1

    Grundsätzlich W ist eine sparse-matrix, und Q (oder np.log(Q)-1) ist eine Dichte matrix. Bei der Multiplikation einer dichten matrix mit einem lichten, das resultierende Produkt wird auch vertreten sein in sparse-matrix-form (was viel Sinn macht).

    Ich bin wahrscheinlich etwas fehlt wirklich hier offensichtlich, und wird am Ende Aussehen wie ein idiot, aber...

    Wenn Q ist eine Dichte matrix, und Sie hoffen, speichern das Ergebnis als eine Dichte matrix, die Sie haben wahrscheinlich genug zu halten W als Dichte-matrix als gut. Das bedeutet:

    W.todense()*(np.log(Q)-1)

    Blick auf die details, wie Sie errechnet haben, in den Kommentaren, so müsste 35.8 GB temporären Speicher. Da hast du 131GB von Daten und das "passt bequem in den Speicher", scheint es zumindest plausibel, dass Sie vorübergehend mit einem anderen 35.8 GB sinnvoll wäre.

    Wenn es nicht angemessen sind, können Sie immer zerlegen Sie die matrix-Multiplikation selbst. Offensichtlich tut es Zeile für Zeile oder Spalte für Spalte machen würde Ihrem ganze Prozess viel langsamer (vielleicht nicht so viel wie schieben den Prozess über den Rand zu tauschen, aber vielleicht noch viel zu langsam, um akzeptabel sein). Aber tun Sie es in, z.B., ein Stück 1GB im Wert von Zeilen in einer Zeit, sollte nicht so schlimm sein. Das würde bedeuten, dass die temporäre Speicherung in der Größenordnung von ein paar GB, und wahrscheinlich nur eine kleine Abkühlung. Natürlich ist es komplizierter und hässlicher code, aber nicht so unüberschaubar.

    InformationsquelleAutor der Antwort abarnert

Schreibe einen Kommentar