Fehler bei .append an eine Liste

[pschmidtke]

Hallo liebe Forummitglieder,

ich bin dabei ein nettes Program für die numerische Integration vom Hodgkin und Huxley Modell zu schreiben. Dazu habe ich Python und C mit Swig vernetzt und rufe demzufolge aus Python verschiedene Funktionen in C auf.

In meinem Programm existiert ebenfalls eine Schleife, die Elemente an eine Liste anhängt.

Code: Alles auswählen

x=[]
for i in range(0,n,step) :
         x.append(hh_euler.getT(data,i))

Leider hab ich ein kleines Problem mit diesem code, da er mir nach einigen Durchläufen die folgende Fehlermeldung anzeigt :

*** glibc detected *** python: realloc(): invalid next size: 0x0874a2c0 ***
======= Backtrace: =========
/lib/libc.so.6[0xb7c10911]
/lib/libc.so.6[0xb7c13598]
/lib/libc.so.6(__libc_realloc+0x100)[0xb7c146b0]
/usr/lib/libpython2.4.so.1.0[0xb7e367ef]
/usr/lib/libpython2.4.so.1.0[0xb7e36922]
/usr/lib/libpython2.4.so.1.0[0xb7e3699d]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4b63)[0xb7e7a383]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x50ae)[0xb7e7a8ce]
/usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x865)[0xb7e7b225]
/usr/lib/libpython2.4.so.1.0[0xb7e3157a]
/usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e19e17]
/usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x80)[0xb7e74ca0]
/usr/lib/python2.4/site-packages/wx-2.6-gtk2-unicode/wx/_core_.so(_ZN12wxPyCallback12EventThunkerER7wxEvent+0xdf)[0xb795b80f]
/usr/lib/libwx_baseu-2.6.so.0(_ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_+0x35)[0xb734c495]
/usr/lib/libwx_baseu-2.6.so.0(_ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent+0x92)[0xb73db342]
/usr/lib/libwx_baseu-2.6.so.0(_ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent+0x62)[0xb73db512]
/usr/lib/libwx_baseu-2.6.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0xa6)[0xb73db5e6]
/usr/lib/libwx_gtk2u_core-2.6.so.0(_ZN12wxWindowBase9TryParentER7wxEvent+0x6b)[0xb768776b]
/usr/lib/libwx_baseu-2.6.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0x7e)[0xb73db5be]
/usr/lib/libwx_gtk2u_core-2.6.so.0(_ZN12wxWindowBase9TryParentER7wxEvent+0x6b)[0xb768776b]
/usr/lib/libwx_baseu-2.6.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent+0x7e)[0xb73db5be]
/usr/lib/libwx_gtk2u_core-2.6.so.0[0xb75cf9b0]
/opt/gnome/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0xb6efd599]
/opt/gnome/lib/libgobject-2.0.so.0(g_closure_invoke+0x11d)[0xb6ef08bd]
/opt/gnome/lib/libgobject-2.0.so.0[0xb6f01531]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb6f02ac7]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit+0x35)[0xb6f02c95]
/opt/gnome/lib/libgtk-x11-2.0.so.0(IA__gtk_button_clicked+0x53)[0xb706e5e3]
/opt/gnome/lib/libgtk-x11-2.0.so.0[0xb706febe]
/opt/gnome/lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0xb6efd599]
/opt/gnome/lib/libgobject-2.0.so.0[0xb6eef0c7]
/opt/gnome/lib/libgobject-2.0.so.0(g_closure_invoke+0x11d)[0xb6ef08bd]
/opt/gnome/lib/libgobject-2.0.so.0[0xb6f016da]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0xb6f02ac7]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit+0x35)[0xb6f02c95]
/opt/gnome/lib/libgtk-x11-2.0.so.0(IA__gtk_button_released+0x53)[0xb706e673]
/opt/gnome/lib/libgtk-x11-2.0.so.0[0xb706e6d1]
/opt/gnome/lib/libgtk-x11-2.0.so.0[0xb713e8fe]
/opt/gnome/lib/libgobject-2.0.so.0[0xb6eef0c7]
/opt/gnome/lib/libgobject-2.0.so.0(g_closure_invoke+0x11d)[0xb6ef08bd]
/opt/gnome/lib/libgobject-2.0.so.0[0xb6f01893]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0xb6f0288f]
/opt/gnome/lib/libgobject-2.0.so.0(g_signal_emit+0x35)[0xb6f02c95]
/opt/gnome/lib/libgtk-x11-2.0.so.0[0xb72295e8]
/opt/gnome/lib/libgtk-x11-2.0.so.0(IA__gtk_propagate_event+0x183)[0xb7138313]
/opt/gnome/lib/libgtk-x11-2.0.so.0(IA__gtk_main_do_event+0x317)[0xb7139567]
/opt/gnome/lib/libgdk-x11-2.0.so.0[0xb6fca58a]
/opt/gnome/lib/libglib-2.0.so.0(g_main_context_dispatch+0x16d)[0xb6c6dabd]
/opt/gnome/lib/libglib-2.0.so.0[0xb6c70cbf]
/opt/gnome/lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0xb6c71069]
/opt/gnome/lib/libgtk-x11-2.0.so.0(IA__gtk_main+0xb4)[0xb71399e4]
/usr/lib/libwx_gtk2u_core-2.6.so.0(_ZN11wxEventLoop3RunEv+0x5b)[0xb7574d6b]
/usr/lib/libwx_gtk2u_core-2.6.so.0(_ZN9wxAppBase8MainLoopEv+0x4e)[0xb761235Abgebrochen


Kennt irgendjemand dieses Problem? Ich bin darüber im Klaren, dass die Methode append ein realloc benutzt um die Liste zu vergrößern, allerdings hilft mir das nicht weiter, um dieses Problem zu lösen.

Vielen Dank für jegliche Hilfe

[Leonidas]

Von dem Stacktrace zu urteilen sieht es wie ein Fehler in wxPython oder sogar eher noch wxWidgets aus.

[sape]

Mein Tipp: Poste den ganzen Code der Funktion, die du in C geschrieben hast, damit jemand der gerade Zeit hat, das selber ausprobieren kann. Vielleicht findet jemand, der öfter mal selber Module in C für Python geschrieben hat, den Fehler.

Ich selber kann dir da nichts raten. Für mich sieht es auf den ersten blick aus, als ob eine Speicherzugriffsverletzungen beim der Allokation oder ähnliches stattfindet. Ist aber nur "geraten".

lg

[pschmidtke]

hab den code gerade nicht hier, der ist allerdings ziemlich lang, kann ihn aber online stellen, falls es notwendig ist.

Das C-Programm läuft allerdings alleine sehr gut und es gibt keinerlei Speicherzugriffsfehler etc. Demzufolge denke ich, dass es der realloc der Funktion append in python ist, die den Fehler hervorruft.


Gibt es eine Alternative zu dieser Funktion?

Danke im Voraus.

Peter Schmidtke

[sape]

Hmm, wenn das Modul selber ohne Fehler läuft wüste ich nicht woran es liegne sollte. An append sollte es eigentlich nicht liegen.

Ne blöde frage:
Macht die Funktion in deinem Modul selber eine Allokation? Und wenn ja, bist du dir auch sicher das du auch auf Sachen wie Speicherknappheit und sonstiges entsprechend reagierst? Ich kann mich noch erinnern was für ein Krampf das in C war mit der Speicherverwaltung und was man da alles berücksichtigen musste. :-[

Naja, bevor ich hier noch weiter wild hineine rate, klinke ich mich mal lieber aus ^^

lg xtra

[pschmidtke]

danke auf jeden Fall für deine Hilfe

das komische ist, wenn ich meinen Funktionsaufruf im append rausnehme und zum Beispiel nur append(1) schreibe...hat also gar nix mit dem Rest zu tun, dann bekomme ich trotzdem diesen Fehler. Versucht Python zu viel Speicher anzulegen? Gibt es da eine Grenze?

Schönen Abend.

[Leonidas]

Versucht Python zu viel Speicher anzulegen? Gibt es da eine Grenze?

Eine Grenze legt das Betriebssystem, diese liegt meistens (wenn ich mich recht erinnere) bei 2 GB pro Prozess.

[sape]

Mein Interpretationsversuch (Kann aber muss nicht stimmen):

Ich weiß auch nicht. Hab mir den Traceback jetzt par mal angeschaut. Ich werde da auch nicht wirklich schlau draus. Fakt (hoffe ich mal) ist das der realloc auf den Speicherbereich 0x0874a2c0 fehlgeschlagen ist, weil die Größe invalid ist. Hmm, als Laie würde ich spontan zu dem Entschluss kommen, das entweder auf einen geschützten Speicherbereich versucht wird zurückzugreifen oder das der Speicher zu ende ist (letzteres kann ich mir aber nicht vorstellen, weil doch Python dafür vorher einen Abbruch mit out of Memory (oder ähnliches) von sich geben würde oder? Beim ersteren weiß ich nicht ob Python dementsprechend auch reagiert mit einer Fehlermeldung, ich denke aber eher nicht).

Ich weiß das 12 Zen von Python ist: Vor Mehrdeutigkeit gestellt, bleib stark und rate nicht.
Aber in den fall ist es wohl angebracht das nicht zu befolgen um an einer Lösung zu kommen

So, /lib/libc.so.6(__libc_realloc+0x100)[0xb7c146b0]: Was ist libc.so? Ist das dein Modul das du geschrieben hast? Auf jeden fall wird da auf 0xb7c146b0 ein realloc versucht. Obs geklappt hat, kA.

Code: Alles auswählen

/usr/lib/libpython2.4.so.1.0[0xb7e367ef] 
/usr/lib/libpython2.4.so.1.0[0xb7e36922] 
/usr/lib/libpython2.4.so.1.0[0xb7e3699d] 
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4b63)[0xb7e7a383] 
/usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x50ae)[0xb7e7a8ce] 
/usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x865)[0xb7e7b225] 
/usr/lib/libpython2.4.so.1.0[0xb7e3157a] 
/usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0xb7e19e17] 
/usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x80)[0xb7e74ca0]

Dieser Teil ist der Traceback von dem aufgerufenen (irgendwas) aus dem Python-Library-Modul das in C geschrieben wurde.

Der Rest ist wx und dann einmal Gnome.

Ich würde weiterhin annehmen dass es an deinem Modul liegen müsste. Du sagst ja das wenn du append mit 1 aufrufst, kommt zwar der Fehler weiterhin, aber ich gehe davon aus das dein Modul weiterhin mit import eingebunden ist oder? Daher könnte es sein das schon beim Importen was den Fehler erzeugt

So nun habe ich genug Spekuliert Ein Sourcecode wäre angebracht damit sich damit mal die Cracks hier beschäftigen können

[Leonidas]

Ich weiß das 12 Zen von Python ist: Vor Mehrdeutigkeit gestellt, bleib stark und rate nicht.

Nein, Punkt 12 ist "In the face of ambiguity, refuse the temptation to guess."

So, /lib/libc.so.6(__libc_realloc+0x100)[0xb7c146b0]: Was ist libc.so? Ist das dein Modul das du geschrieben hast? Auf jeden fall wird da auf 0xb7c146b0 ein realloc versucht. Obs geklappt hat, kA.

Das ist die glibc2, welche die libc6 implementiert:

GNU C Library: Shared libraries

Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others.

Der Rest ist wx und dann einmal Gnome.

Der Rest ist wxGTK welches auf GTK+ 2 aufbaut, GNOME wird nicht benutzt. libgobject, libgdk-x11, libgtk-x11 sind alles Teile von GTK+, libglib wird vom GTK+-Team für GTK+ entwickelt.

Was passiert, wenn du deine C-Extension in ein Programm ohne wxPython einbaust, und es dort extensiv testest?

[sape]

Ich weiß das 12 Zen von Python ist: Vor Mehrdeutigkeit gestellt, bleib stark und rate nicht.

Nein, Punkt 12 ist "In the face of ambiguity, refuse the temptation to guess."

Ich kann doch kein English, das weißt du doch Daher habe ich mich daran gehalten -> http://paste.pocoo.org/show/74/

[Joghurt]

Das "tolle" an C ist, dass Fehler im Code sich nicht dort bemerkbar machen müssen, wo sie sind, sondern unabhängige Teile des Codes zum Absturz bringen. So etwas scheint bei dir der Fall zu sein. Vielleicht überschreibt der Code an einer Stelle ein bisschen vom Stack, und das führt später zu Chaos.

Es gibt Tools wie Valgrind, mit denen man solchen Fehlern auf die Spur kommen kann.