eigene Bibliothek macht Probleme :(

SBond

Hallo Leute,

ich habe irgendwie massive Probleme eine eigene Lib zum laufen zu bekommen. Diese ist recht umfangreich und funktioniert als ausführbares Programm problemlos. Alle Tests sind erfolgreich und Valgrind zeigt keinerlei Fehler. Wenn ich jetzt meinen Code als statische Lib kompiliere und diese in ein neues (quasi leeres) Projekt einbinde und die entsprechenden Funktionen aus der Lib aufrufe, dann stürzt das Programm ab. Oft an unterschiedlichen Stellen. Valgrind spuckt hierbei massive Fehler aus:

==26907== Invalid read of size 2
==26907==    at 0x444D832: getenv (/build/glibc-En_RtM/glibc-2.19/stdlib/getenv.c:85)
==26907==    by 0x44C5FBD: tzset_internal (/build/glibc-En_RtM/glibc-2.19/time/tzset.c:413)
==26907==    by 0x44C630E: __tz_convert (/build/glibc-En_RtM/glibc-2.19/time/tzset.c:632)
==26907==    by 0x44C4A4C: localtime (/build/glibc-En_RtM/glibc-2.19/time/localtime.c:42)
==26907==    by 0x8064C59: currentDateTime(std::string) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/general/globalFunctions.cpp:82)
==26907==    by 0x805FFB8: NtsLogger::log(std::string, std::string, std::string) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/general/NtsLogger.cpp:152)
==26907==    by 0x80E49FA: ServerSessionInfo::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/ServerSessionInfo.cpp:115)
==26907==    by 0x80CC7A8: NtsUnicastServer::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastServer.cpp:43)
==26907==    by 0x804E547: NtsUnicastService::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastService.cpp:130)
==26907==    by 0x804D669: main (/media/sf_NTS/Workspace/Test_NTS/Debug/../src/Test_NTS.cpp:15)
==26907==  Address 0x1 is not stack'd, malloc'd or (recently) free'd
==26907== 
==26907== 
==26907== Process terminating with default action of signal 11 (SIGSEGV)
==26907==  Access not within mapped region at address 0x1
==26907==    at 0x444D832: getenv (/build/glibc-En_RtM/glibc-2.19/stdlib/getenv.c:85)
==26907==    by 0x44C5FBD: tzset_internal (/build/glibc-En_RtM/glibc-2.19/time/tzset.c:413)
==26907==    by 0x44C630E: __tz_convert (/build/glibc-En_RtM/glibc-2.19/time/tzset.c:632)
==26907==    by 0x44C4A4C: localtime (/build/glibc-En_RtM/glibc-2.19/time/localtime.c:42)
==26907==    by 0x8064C59: currentDateTime(std::string) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/general/globalFunctions.cpp:82)
==26907==    by 0x805FFB8: NtsLogger::log(std::string, std::string, std::string) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/general/NtsLogger.cpp:152)
==26907==    by 0x80E49FA: ServerSessionInfo::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/ServerSessionInfo.cpp:115)
==26907==    by 0x80CC7A8: NtsUnicastServer::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastServer.cpp:43)
==26907==    by 0x804E547: NtsUnicastService::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastService.cpp:130)
==26907==    by 0x804D669: main (/media/sf_NTS/Workspace/Test_NTS/Debug/../src/Test_NTS.cpp:15)
==26907==  If you believe this happened as a result of a stack
==26907==  overflow in your program's main thread (unlikely but
==26907==  possible), you can try to increase the size of the
==26907==  main thread stack using the --main-stacksize= flag.
==26907==  The main thread stack size used in this run was 8388608.
==26907== 14 bytes in 1 blocks are possibly lost in loss record 361 of 830
==26907==    at 0x402970C: operator new(unsigned int) (/build/valgrind-JHdRzs/valgrind-3.10.0/coregrind/m_replacemalloc/vg_replace_malloc.c:318)
==26907==    by 0x4376EC5: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x4378E6A: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x4379407: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x805FC5A: NtsLogger::log(std::string, std::string, std::string) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/general/NtsLogger.cpp:103)
==26907==    by 0x80E49FA: ServerSessionInfo::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/ServerSessionInfo.cpp:115)
==26907==    by 0x80CC7A8: NtsUnicastServer::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastServer.cpp:43)
==26907==    by 0x804E547: NtsUnicastService::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastService.cpp:130)
==26907==    by 0x804D669: main (/media/sf_NTS/Workspace/Test_NTS/Debug/../src/Test_NTS.cpp:15)
==26907== 
==26907== 16 bytes in 1 blocks are possibly lost in loss record 661 of 830
==26907==    at 0x402970C: operator new(unsigned int) (/build/valgrind-JHdRzs/valgrind-3.10.0/coregrind/m_replacemalloc/vg_replace_malloc.c:318)
==26907==    by 0x4376EC5: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x8059E1F: char* std::string::_S_construct<char*>(char*, char*, std::allocator<char> const&, std::forward_iterator_tag) (/usr/include/c++/4.9/bits/basic_string.tcc:138)
==26907==    by 0x8059D43: char* std::string::_S_construct_aux<char*>(char*, char*, std::allocator<char> const&, std::__false_type) (/usr/include/c++/4.9/bits/basic_string.h:1743)
==26907==    by 0x8059D29: char* std::string::_S_construct<char*>(char*, char*, std::allocator<char> const&) (/usr/include/c++/4.9/bits/basic_string.h:1764)
==26907==    by 0x8059CFA: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string<char*>(char*, char*, std::allocator<char> const&) (/usr/include/c++/4.9/bits/basic_string.tcc:229)
==26907==    by 0x8059B8D: std::string __gnu_cxx::__to_xstring<std::string, char>(int (*)(char*, unsigned int, char const*, char*), unsigned int, char const*, ...) (/usr/include/c++/4.9/ext/string_conversions.h:99)
==26907==    by 0x8059634: std::to_string(int) (/usr/include/c++/4.9/bits/basic_string.h:2901)
==26907==    by 0x80E48D1: ServerSessionInfo::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/ServerSessionInfo.cpp:115)
==26907==    by 0x80CC7A8: NtsUnicastServer::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastServer.cpp:43)
==26907==    by 0x804E547: NtsUnicastService::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastService.cpp:130)
==26907==    by 0x804D669: main (/media/sf_NTS/Workspace/Test_NTS/Debug/../src/Test_NTS.cpp:15)
==26907== 
==26907== 18 bytes in 1 blocks are possibly lost in loss record 666 of 830
==26907==    at 0x402970C: operator new(unsigned int) (/build/valgrind-JHdRzs/valgrind-3.10.0/coregrind/m_replacemalloc/vg_replace_malloc.c:318)
==26907==    by 0x4376EC5: std::string::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x4378E6A: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x4379407: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/i386-linux-gnu/libstdc++.so.6.0.20)
==26907==    by 0x80E49C4: ServerSessionInfo::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/ServerSessionInfo.cpp:115)
==26907==    by 0x80CC7A8: NtsUnicastServer::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastServer.cpp:43)
==26907==    by 0x804E547: NtsUnicastService::initialization(std::string const&) (/media/sf_NTS/Workspace/NTS_Unicast_Service/Build_Lib_Release/../src/NtsUnicastService.cpp:130)
==26907==    by 0x804D669: main (/media/sf_NTS/Workspace/Test_NTS/Debug/../src/Test_NTS.cpp:15)
==26907==

u.v.m.

Nun frage ich mich, was der Fehler ist. Sollte wirklich der Stack zu klein sein? Der Stack wird laut 'massif' meist um die 20 KB belastet, da alles größere im heap geschieht. Da ich vorher noch nie mit statischen Libs gearbeitet habe, könnte ich möglicherweise weise etwas beim Kompilieren vergessen haben. ...bin mir nicht sicher, ob man was besonderes beachten muss.

hier mal kurz die main():

#include "nts/NtsUnicastService.h"

main ()
{
	try
	{
		NtsUnicastService nts;
		nts.initialization("./config/nts/global.ini");
	}
	catch (std::string const &e)
	{
		std::cerr << "NTS error: " << e << std::endl;
	}
	catch (...)
	{
		std::cerr << "oops, unknown error" << std::endl;
	}
}

Wenn ich diesen Code im Projekt (NtsUnicastService als Programm) ausführe ist alles gut. Wenn ich das Projekt als statische Lib kompiliere, das in einem neuen Projekt integriere und den Code (die main()) ausführe, dann kommen die Probleme. Eine Exception wird nicht geworfen. Das Programm wird irgendwo innerhalb der nts.initialization() einfach abgebrochen.

Die Lib (NtsUnicastService.a) ist mit Debug-Infos ca. 40 MB groß und ohne ca. 3,5 MB. Im Test-Projekt habe ich in den Projketeinstellungen den Linkerflag (-lNtsUnicastService) hinzugefügt und die Pfade gesetzt. Das Kompilieren und Linken funktioniert auch soweit, daher weiß ich nicht was falsch sein könnte.

hatte jemand schonmal solche Probleme? Habe ich irgendwas wichtiges vergessen? ...bin ratlos

PS: ich programmiere unter Linux Debian mit Eclipse CDT

viele Grüße,
SBond

Eine statische Bibliothek auf Unix ist nichts weiter als ein Sack voll Objectfiles. Ich würde auf verschiedene Compiler, Sprachversionen oder sonstige Compileschalter tippen.

Ich kann es mir zwar nicht vorstellen, ich würde aber trotzdem mal probieren, ob der VirtualBox shared folder Effekte hat.

std::string als Exception ist eine blöde Idee.

SBond

danke für die tipps
Ich schau mal ob es was bewirkt .

Danke

SBond

Habe das Problem gefunden. Die Header der Lib und des inkludierenden Projekts wichen ab.

Habe gleich mal eine Frage dazu. Aber zunächst mal ein Codebeispiel:

Die Lib: main.cpp:

#include <iostream>
#include "./MyLib.h"

using namespace std;

int main() {
	std::cout << "program start" << endl;

	MyLib myLib;
	myLib.say("Hello");

	std::cout << "program end" << endl;
	return 0;
}

Die Lib: MyType.h:

#ifndef MYLIB_H_
#define MYLIB_H_

#include <iostream>
#include <string>

#include "./MyType.h"
#include "./AnotherType.h"

class MyLib
{

public:

	MyLib();
	virtual ~MyLib();

	void say(std::string const &text);

private:
	MyType       m_myType;
	AnotherType  m_anotherType;

};

#endif /* MYLIB_H_ */

Das zweite Projekt, das die Lib verwendet: MyType.h:

#ifndef MYLIB_H_
#define MYLIB_H_

#include <iostream>
#include <string>

class MyLib
{

public:

	MyLib();
	virtual ~MyLib();

	void say(std::string const &text);

};

#endif /* MYLIB_H_ */

Die untere MyLib.h beinhaltet nicht mehr die Membervariablen. Wird das Projekt erzeugt, so lässt es sich kompilieren, linken und ausführen. Allerdings kommt es zu diesen Fehlern und Abstürzen. Um das zu vermeiden müsste ich nun den MyLib.h aus der Lib verwenden (mit den Membervariablen). Dann läuft alles problemlos. ...allerdings müsste ich nun auch die Header (MyType und AnotherType) in das Projekt hinzufügen, das die Lib verwenden will. Das betrifft dann auch wieder rekursiv alle eingebundenen Header. Kann man das irgendwie umgehen?

Ich würde also gerne eine Lib liefern, mit der zugängliche Schnittstelle als EINE Header-Datei. Oder muss ich immer neben der Lib alle Header-Dateien bereitstellen?

viele Grüße,
SBond

Die Idee war schon vernünftig, du darfst aber die One Definition Rule nicht verletzen. Hier würde sich Pimpl anbieten.

SBond

Danke für den Tipp.

Mit den Pimpl-Idiom habe ich bislang noch nicht gearbeitet. Ich werde mich da erstmal etwas einlesen.
Zumindest war der erste Ansatz nicht ganz verkehrt

viele Grüße,
SBond

SBond

Nochmals Danke

'Pimpl' war genau das richtige. Jetzt funktioniert alles richtig *freu*

Dane für den Tipp