shlib Version ändert sich von Programm zu Programm

Vom einfachen Programm zum fertigen Debian-Paket, Fragen rund um Programmiersprachen, Scripting und Lizenzierung.
Antworten
reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

shlib Version ändert sich von Programm zu Programm

Beitrag von reox » 08.09.2017 11:26:19

So genau weiß ich auch nicht was als Betreff rein soll, denn ich bin recht ratlos was das für ein Problem sein soll:
In FreeCAD 0.17 gibts einen segfault, wenn man einen expat XML Parser aufmacht. Wenn man zB freecad-daily installiert (von launchpad) kann man einfach segfaulten, wenn man das hier in die python konsole reinwirft:

Code: Alles auswählen

from xml.parsers import expat
expat.ParserCreate()
Wenn ich eine python shell oder ipython so aufmache, klappt das ohne Probleme.

Nun hab ich herausgefunden, dass das expat Modul in freecad angibt mit libexpat 2.0.1 zu laufen. Außerdem sind die features anders. Allerdings sagt er mir, es ist die selbe version und die selbe bytecode datei:

Code: Alles auswählen

>>> expat.features
[('sizeof(XML_Char)', 1), ('sizeof(XML_LChar)', 1)]
>>> expat.EXPAT_VERSION
'expat_2.0.1'
>>> expat.__file__
'/usr/lib/python2.7/xml/parsers/expat.pyc'
>>> expat.__version__
'$Revision: 17640 $'
zum vergleich hier mal die ausgabe in einer python shell:

Code: Alles auswählen

>>> expat.features
[('sizeof(XML_Char)', 1), ('sizeof(XML_LChar)', 1), ('XML_DTD', 0), ('XML_CONTEXT_BYTES', 1024), ('XML_NS', 0)]
>>> expat.EXPAT_VERSION
'expat_2.2.3'
>>> expat.__file__
'/usr/lib/python2.7/xml/parsers/expat.pyc'
>>> expat.__version__
'$Revision: 17640 $'
Nun dachte ich erst, die verwenden da am launchpad eine alte version von libexpat zum bauen, allerdings sieht man im buildlog, dass sie libexpat1 2.2.3-1 verwenden.
Das ist auch die gleiche wie bei mir installiert (nur eben aus ubuntu).

Ich hab im source von pyexpat.c nachgeschaut und dort wird EXPAT_VERSION über die Funktion XML_ExpatVersion() gesetzt:

Code: Alles auswählen

    PyModule_AddStringConstant(m, "EXPAT_VERSION",                                                                                                                                                                                                                                                                                                                        
                               (char *) XML_ExpatVersion());    
Ich verstehe daher nicht, wie die Version in FreeCAD auf einmal 2.0.1 sein kann?!
Vor allem weil ein:

Code: Alles auswählen

$ ldd /usr/bin/freecad-daily | grep expat
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f899e424000)
liefert und /lib/x86_64-linux-gnu/libexpat.so.1 die version aus libexpat1:amd64 ist, was bei mir auch 2.2.3 ist?!
XML_ExpatVersion() baut den Versionsstring aus den in expat.h definierten Macros zusammen. Ich finde aber nirgends eine Version in der was anderes steht als 2.2.3...

ebenso ist pyexpat die selbe .so, allerdings in zwei verschiedenen versionen?

Code: Alles auswählen

# Freecad
>>> import pyexpat
>>> pyexpat.__file__
'/usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so'
>>> pyexpat.EXPAT_VERSION
'expat_2.0.1'
vs

Code: Alles auswählen

python
>>> import pyexpat
>>> pyexpat.__file__
'/usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so'
>>> pyexpat.EXPAT_VERSION
'expat_2.2.3'
Um jetzt alle unsicherheiten auszuschließen, hab ich das ganze Paket selber gebaut (per apt-get source freecad-daily die version von launchpad). Dabei ist mir aufgefallen, dass die Variable ${shlibs:Depends} dann später libexpat1 >= 2.0.1 enthält. Ich vermute, dass festgestellt wird, dass libexpat1 2.2.3 und 2.0.1 zumindest von der API gleich sind und daher auch 2.0.1 verwendet werden kann? Aber was macht denn das für einen Sinn? Wieso kann der Rückgabewert eine Funktion, welche auf konstanten zurückgreift sich auf einmal ändern?
Ich war erst der Meinung das es sich bei dem Segfault um einen Bug in pyexpat oder expat selber handelt, aber mir scheint es ist einfach ein Build Problem und FreeCAD glaubt einfach eine alte Version zu verwenden?

pferdefreund
Beiträge: 3791
Registriert: 26.02.2009 14:35:56

Re: shlib Version ändert sich von Programm zu Programm

Beitrag von pferdefreund » 08.09.2017 19:24:11

.... aus Ubuntu ? Hast du Debian oder Ubuntu. Wenn Debian, dann libs aus Ubuntu muss nicht wirklich funktionieren - je nach Compilerversion usw......

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: shlib Version ändert sich von Programm zu Programm

Beitrag von reox » 08.09.2017 20:37:33

pferdefreund hat geschrieben: ↑ zum Beitrag ↑
08.09.2017 19:24:11
.... aus Ubuntu ? Hast du Debian oder Ubuntu. Wenn Debian, dann libs aus Ubuntu muss nicht wirklich funktionieren - je nach Compilerversion usw......
wie gesagt, ich hab die launchpad version installiert, dann aber das paket bei mir lokal (debian buster/sid) neu gebaut. Daran kann es also nicht liegen.

Cae
Beiträge: 6349
Registriert: 17.07.2011 23:36:39
Wohnort: 2130706433

Re: shlib Version ändert sich von Programm zu Programm

Beitrag von Cae » 09.09.2017 00:32:05

Interessanter Fehler, bisher ist mein Freecad immer viel langweiliger gesegfaultet...

Das ist mehr ein Schuss in's Blaue, aber foo.__file__ ist einfach nur ein magischer Name, aber nicht irgendwie schreibgeschuetzt. Ebenso bar.EXPAT_VERSION. Vielleicht siehst du da falsche Werte. Du koenntest mal beides mit strace -e file -o log -f {program} starten, um zu erfassen, was tatsaechlich geladen wird (oder zumindest geoeffnet oder gerade nicht geoeffnet).

Gruss Cae
If universal surveillance were the answer, lots of us would have moved to the former East Germany. If surveillance cameras were the answer, camera-happy London, with something like 500,000 of them at a cost of $700 million, would be the safest city on the planet.

—Bruce Schneier

reox
Beiträge: 2459
Registriert: 06.06.2006 22:09:47
Lizenz eigener Beiträge: MIT Lizenz

Re: shlib Version ändert sich von Programm zu Programm

Beitrag von reox » 10.09.2017 11:37:47

Im FreeCAD Forum hat jetzt ein Entwickler genauer geschaut und sie sind der Meinung, dass libcoin80v5 daran schuld ist https://bugs.debian.org/cgi-bin/bugrepo ... bug=874727
So wie es ausschaut verwendet libcoin eine eigene libexpat und da kommt dann die Version her...

@Cae: Ja, das wird wohl direkt von dort gelesen:
Hier wenn man strace -e file -o log -f python startet und dort

Code: Alles auswählen

import pyexpat
pyexpat.__file__
pyexpat.__EXPAT_VERSION
ausführt: pastebin/?mode=view&s=39968

Bei FreeCAD ist das nicht mehr so eindeutig, da viele Module selber pyexpat laden.
Allerdings sieht man auch wieder, dass er dann diese Datei öffnet:

Code: Alles auswählen

2182  open("/usr/lib/python2.7/lib-dynload/pyexpat.x86_64-linux-gnu.so", O_RDONLY|O_CLOEXEC) = 32       
Nachdem er überall nach passenden Dateien gesucht hat. Danach kommt aber kein Laden der libexpat mehr, da wohl schon geladen...

Was ich nicht ganz verstehe, ist dass libcoin trotzdem dynamisch gelinked ist:

Code: Alles auswählen

$ file /usr/lib/x86_64-linux-gnu/libCoin.so.80.0.0
/usr/lib/x86_64-linux-gnu/libCoin.so.80.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=13c8a5a3ee7691d232d30f39dbe032819511d237, stripped
aber es stimmt schon, in coin gibt es im configure file ein flag für:

Code: Alles auswählen

--enable-system-expat   enable use of system-expat
und wenn man das paket baut zeigt er das an:

Code: Alles auswählen

Coin configuration settings:
  [...]
  Use system expat:         No (default)
  [...]

Ich hab das testweise mal ins rules file dazugegeben und libcoin neu gebaut, jetzt bekomme ich den segfault gleich beim starten:

Code: Alles auswählen

Program received signal SIGSEGV, Segmentation fault.
#0  /lib/x86_64-linux-gnu/libc.so.6(+0x33060) [0x7f6d5bc07060]
#1  /usr/lib/x86_64-linux-gnu/libCoin.so.80(cc_memalloc_deallocate+0) [0x7f6d62ecfe20]
#2  0x7f6d6302aeb6 in SoType::createType(SoType, SbName, void* (*)(), unsigned short) from /usr/lib/x86_64-linux-gnu/libCoin.so.80+0x396
#3  0x7f6d62f3b77b in SoGLCacheContextElement::initClass() from /usr/lib/x86_64-linux-gnu/libCoin.so.80+0x6b
#4  0x7f6d62f19f1f in SoElement::initElements() from /usr/lib/x86_64-linux-gnu/libCoin.so.80+0x18f
#5  0x7f6d62f1a03f in SoElement::initClass() from /usr/lib/x86_64-linux-gnu/libCoin.so.80+0x8f
#6  0x7f6d6301228e in SoDB::init() from /usr/lib/x86_64-linux-gnu/libCoin.so.80+0x19e
#7  0x7f6d655f62e8 in Gui::Application::runApplication() from /usr/lib/freecad-daily/lib/libFreeCADGui.so+0x9c8
#8  freecad-daily(main+0x641) [0x5599da250461]
#9  /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f6d5bbf42e1]
#10  freecad-daily(_start+0x2a) [0x5599da25152a]
scheint so, als müssten sie den code mal gegen eine neue expat library linken...

Antworten