ich habe ein sehr merkwürdiges Problem, das sich schwer beschreiben lässt. Ich hoffe mal mir kann trotzdem geholfen werden.

Ich habe eine Klasse in eine Library gepackt. Diese Klasse ist im Prinzip ein C++ Wrapper für von Matlab/Simulink generierten C-Code.

Die Test-Binary wird gegen diese Library gelinkt und funktioniert ohne Probleme. Wenn ich jetzt versuche die Library in mein größeres Projekt einzubinden schlägt das immer fehl. Ich kann alles kompilieren, aber beim Ausführen erhalte ich folgenden Fehler:

*** glibc detected *** /home/simon/ros_workspace/orocos_toolchain/ocl/bin/deployer-gnulinux: malloc(): memory corruption: 0x09b489f8 ***

Der Fehler kommt dabei immer wenn eine Instanz der Klasse aus der Library erstellt wird. Er kommt auch gar nicht in den Konstruktor rein, sondern der Fehler scheint schon vorher zu passieren. Ich kann das Problem leider nicht weiter eingrenzen, weil ich keinen Zugriff auf das Programm habe, dass die Library aufruft. Wenn ich aber die Zeile auskommentiere, bei der die Instanz erstellt wird, läuft alles durch.

Gehe ich recht in der Annahme, das man anhand dieser Informationen nichts über das Problem sagen kann? Wo könnte denn der Fehler liegen? Ich finde es äußerst merkwürdig, dass ich mit Projekt A ohne Probleme Instanzen der Klasse erstellen kann, Projekt B aber nicht funktioniert. Daraus schließe ich eigentlich, dass der Fehler bei Projekt B liegen muss. Ich kann mal den Konstrukor schreiben, das bringt aber denke ich auch nicht viel:

BiobipedRSimDevice::BiobipedRSimDevice()
    : simulationStarted(false),
      enable(false),
      setup(false),
      oldBioBipedyBodyMsgValid(false),
      model(BioBiped()),
      dataLoggingActive(false),
      dtSim(0.001) {
    if (ssGetErrorStatus(model))
        cout << "Error during model registration: " << ssGetErrorStatus(model) << endl;
}

Wenn ich statt BioBiped() NULL schreibe bleibt die Fehlermeldung weiterhin, daran kann es also auch nicht liegen.

PS: Arbeite mit CMake und Standardcompiler unter Ubuntu.

Da du mit Linux arbeitest: man mallopt

Grundsätzlich ist das aber kein C++-Problem => falsches Forum

Projekt A kann eine Instanz der Klasse erstellen.
Projekt B kann keine Instanz der Klasse erstellen.

Die Klasse und speziell der Konstruktor sind aber ja eigentlich unabhängig vom Projekt, weil sie nur eingebunden werden. Finde das Ganze sehr merkwürdig.

Was kann denn generell dazu führen, dass so etwas passiert?

Die Fehlermeldung deutet darauf hin, dass über die Grenzen eines dynamischen Arrays hinaus geschrieben wurde. Theoretisch kann solch ein Fehler natürlich auch aus allerlei anderen Gründen auftreten, aber das ist mein Tipp.

Da du anscheinend unter Linux entwickelst, kann ich dir nur sehr die Benutzung von valgrind empfehlen. Jedes deiner Programme sollte unter

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes dein_programm

fehler- und warnungsfrei laufen. A propos Warnungen: Compilerwarnungen auf Maximum, gerade die Warnungen des GCC sind sehr gut. Warnungen wie Compilerfehler behandeln. Der GCC bietet außerdem eine Debugruntime an, die man mittels -D_GLIBCXX_DEBUG bei der Übersetzung aktivieren kann.

gerade die Warnungen des GCC sind sehr gut.

Naja, die üblichen falschen Warnung sind da aber trotzdem: warning: no return statement in function returning non-void, wobei diese Situation nie eintreten kann, weil ein switch vorher returnt, warning: [enum_elem] not handled in switch, wobei es überflüssig ist es zu behandeln, ...

Liegt vielleicht an Projekt B oder an der Basisklasse oder an unterschiedliche mallocs aus verschiedenen Runtime-Bibliotheken.

Was heißt aus unterschiedlichen Runtime-Bibliotheken? Sowas könnte am Ehesten hinhauen. Der Fehler tritt wohl in einer Matlab-Bibliothek auf. Die wurde also nicht von mir selbst kompiliert.

SeppJ schrieb:

mikemodanoxxx schrieb:

Was kann denn generell dazu führen, dass so etwas passiert?

Die Fehlermeldung deutet darauf hin, dass über die Grenzen eines dynamischen Arrays hinaus geschrieben wurde. Theoretisch kann solch ein Fehler natürlich auch aus allerlei anderen Gründen auftreten, aber das ist mein Tipp.

Da du anscheinend unter Linux entwickelst, kann ich dir nur sehr die Benutzung von valgrind empfehlen. Jedes deiner Programme sollte unter

valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes dein_programm

fehler- und warnungsfrei laufen. A propos Warnungen: Compilerwarnungen auf Maximum, gerade die Warnungen des GCC sind sehr gut. Warnungen wie Compilerfehler behandeln. Der GCC bietet außerdem eine Debugruntime an, die man mittels -D_GLIBCXX_DEBUG bei der Übersetzung aktivieren kann.

Ja ich hatte es schon mit valgrind versucht (bzw mit alleyoop), das hat mich aber nicht weitergebracht.

==18298== Invalid write of size 4
==18298==    at 0x451B674: pthread_cond_init@@GLIBC_2.3.2 (pthread_cond_init.c:40)
==18298==    by 0xFAD277C: ??? (in /usr/local/MATLAB/R2012a/bin/glnx86/libmwservices.so)
==18298==    by 0xF9A3E5B: ??? (in /usr/local/MATLAB/R2012a/bin/glnx86/libmwservices.so)
==18298==    by 0x400EE38: call_init (dl-init.c:70)
==18298==    by 0xBECB1152: ???
==18298==    by 0x4E45504E: ???

Hilft mir das in irgendeiner Weise?

edit: Ich habe grade mal geschaut. Ich habe die glibc-Version 2.13.1. Falls es an den unterschiedlichen Versionen liegt: Kann man das irgendwie umgehen?
edit2: sorry, 2.15 meinte ich

Hilft mir das in irgendeiner Weise?

Wenn du mit Debugsymbolen (und möglichst ohne Optimierung) compilierst: Sehr sogar! Damit hast du den Fehler genau lokalisiert.
Ohne Debugsymbole: Nun, nicht so sehr, wie du selber merkst. Du weißt bloß, da ist ein Programmierfehler.