7170 friert ein mit neuer download-toolchain

[hermann72pb]

Zwischen R6071 und R6089 scheint irgendwas gelaufen zu sein, was das Bauen von einem stabilen Image für eine 7170 nicht möglich macht. Ich hatte bereits neu ausgecheckt, 2 oder 3 unterschiedliche Konfigurationen von Paketen ausprobiert. Nichts hilft.

MfG

 

[cuma]

Gute Idee. Wenn man in make/libs/libfreetz.mk die Version wieder auf 0.2 änderst, bootet die 7170 wieder. Allerdings gibt es dann noch Probleme, wie zB ein Segfault von openntpd

$ strace -f  ntpd -s -f /mod/etc/ntpd.conf
execve("/usr/sbin/ntpd", ["ntpd", "-s", "-f", "/mod/etc/ntpd.conf"], [/* 181 vars */]) = 0
old_mmap(NULL, 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaad000
stat("/etc/ld-uClibc.so.cache", 0x7fb26818) = -1 ENOENT (No such file or directory)
open("/usr/lib/freetz/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/mod/lib/libgcc_s.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=180544, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaae000
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\360\306\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 245760, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aabe000
old_mmap(0x2aabe000, 176700, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x2aabe000
old_mmap(0x2aaf9000, 3136, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x2b000) = 0x2aaf9000
close(7)                                = 0
munmap(0x2aaae000, 4096)                = 0
open("/usr/lib/freetz/libc.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/mod/lib/libc.so.0", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/lib/libc.so.0", O_RDONLY)        = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=460188, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaae000
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\10\0\1\0\0\0\240\253\0\0004\0\0\0"..., 4096) = 4096
old_mmap(NULL, 503808, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aafa000
old_mmap(0x2aafa000, 407636, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x2aafa000
old_mmap(0x2ab6d000, 8208, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x63000) = 0x2ab6d000
old_mmap(0x2ab70000, 18736, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ab70000
close(7)                                = 0
munmap(0x2aaae000, 4096)                = 0
open("/mod/lib/libc.so.0", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/lib/libc.so.0", O_RDONLY)        = 7
fstat(7, {st_mode=S_IFREG|0644, st_size=460188, ...}) = 0
close(7)                                = 0
stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=22608, ...}) = 0
mprotect(0x2ab6d000, 4096, PROT_READ)   = 0
mprotect(0x2aabc000, 4096, PROT_READ)   = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

 

[hermann72pb]

Das heißt doch libfreetz und nicht die toolchain? Soll ich das Thema hier umbenennen?
Ich hatte mir schon die ganzen Änderungen im trunk zwischen 6071 und 6089 durchgeschaut. Du hast Recht, dass es nur entweder toolchain oder diese libfreetz-Geschichte mit Benutzerverwaltung sein könnte. Ich dachte aber, Ralf hatte es auf einer 7170 bereits getestet, oder war es eine andere Box bei ihm?

MfG

 

[RalfFriedl]

Ich habe einen W900V, der auf 7170 Firmware basiert.
Bei mir lief die ursprüngliche Version, danach gab es aber noch Änderungen für die 7270.

Das Problem mit openntpd habe ich auch. Anscheinend definiert die C-Library die Variable __progname, sie wird aber nicht initialisiert, was zu einen Speicherzugriffsfehler führt.
Die richtige Lösung wäre, für eine richtige Initialisierung zu sorgen oder die Definition zu entfernen.
Ich habe mir damit beholfen, daß ich openntpd-3.9p1/openbsd-compat/bsd-misc.c:53 geändert habe auf "#ifdef X_HAVE___PROGNAME".

 

[er13]

@cuma: Danke, habe das gleiche Problem, hatte auch libfreetz in Verdacht, muss jetzt nicht testen ;-)

das mit __progname weiß ich und dachte wir haben es korrigiert, ist ein uClibc-Fehler

 

[cuma]

openntpd lief bis vor ein paar Tagen bei mir. Müsste eigenlich auch von aktuellen Änderungen am trunk ausgelöst sein. Sind dann wohl 2 unabhängige Probleme?

 

[RalfFriedl]

Es sind auf jeden Fall zwei unabhängige Probleme. Libfreetz wird nur für den ctlmgr verwendet.

Was und wann wurde denn wegen __progname geändert?

 

[hermann72pb]

Also Einfrieren hat definitiv etwas mit libfreetz zu tun. Ralf schaut es sich an und macht es wieder heile.
Ihr könnt hier auch ruhig openntpd diskutieren, dann ändere ich die Überschrift. Oder lagert es irgendwo anders aus und diskutiert dort, wenn wir uns hier libfreetz alleine widmen sollten.

MfG

 

[er13]

Ich habe den Version Bump revertet bis wir (Ralf ;-)) das mal gefixed haben...

 

[RalfFriedl]

Das Einfrieren ist bei mir mit der aktuellen Library auch. Anscheinend kommt der Linker in eine Endlosschleife. Ich bekomme es weg, wenn ich nicht die libusbcfg.so.1 mit zur Library linke.
Dann stürzt aber der ctlmgr ab. Das bekomme ich weg, wenn ich das "extern" von "USBCFG_config" entferne.

Ich weiß aber nicht, was passiert, wenn man das dann wieder auf einer 7270 laufen läßt.

 

[cuma]

Das Problem mit openntpd habe ich auch. Anscheinend definiert die C-Library die Variable __progname, sie wird aber nicht initialisiert, was zu einen Speicherzugriffsfehler führt.

das mit __progname weiß ich und dachte wir haben es korrigiert, ist ein uClibc-Fehler

Dumm dass beide Probleme gleichzeitig aufgetreten sind. Könnte es durch eine andere Compilerversion verursacht werden? Ansonsten hat sich ja nichts geändert

 

[er13]

wegen __progname: versucht in der Konfigdatei von uClibc (Config.mod.0.9.29) das Symbol UCLIBC_HAS_PROGRAM_INVOCATION_NAME zu aktivieren (UCLIBC_HAS_PROGRAM_INVOCATION_NAME=y). Wenn ich es richtig in Erinnerung habe, sollte das helfen. Bin jetzt in der Arbeit, kann es selbst erst heute Abend testen...

p.s. nur zur Sicherheit, die toolchain muss danach natürlich neu gebaut werden

edit:
@Ralf: kann es sein, dass man es doch gegen libusbcfg linken soll, diese aber dann auch explizit in LD_PRELOAD mitangeben und zwar vor libfreetz?

 

[RalfFriedl]

libusbcfg in LD_PRELOAD vor libfreetz?

Das kann man versuchen, aber warum so umständlich, wenn es ohne extern funktioniert?

 

[olistudent]

Warum tritt der Fehler nur mit der 7170 auf und nicht auf der 7270?

MfG Oliver

 

[er13]

tritt er höchstwahrscheinlich auch auf, s. #1078, die beschrieben Symptome sind absolut identisch zu dem wie es bei mir aussah

Zitat: "leuchtet nur noch die Power LED und kann die Box nicht mehr erreichen"

 

[RalfFriedl]

Ansonsten wäre es denkbar, daß es Unterschiede im dynamischen Loader gibt, vielleicht hat der auch einen Fehler. Aber ohne Debug-Ausgaben aus dem Loader kommt man dem wohl nicht so leicht auf die SPur.

 

[cuma]

Openntpd läuft wieder mit der Änderung aus http://www.ip-phone-forum.de/showpost.php?p=1629602&postcount=4 von RalfFriedl, Toolchain bauen dauert mir zu lange

 

[olistudent]

Ich bin mir zwar nicht sicher wo das jetzt herkommt. Aber openwrt hatte da wohl mal das gleiche Problem.
https://dev.openwrt.org/ticket/2941

Gruß
Oliver

 

[RalfFriedl]

Sieht aus, als wäre es das Gleiche.
Wobei ich den Eindruck habe, daß es eine Option gibt, um die Variable __progname zu definieren, und die andere Option, damit diese Variable auch einen Wert bekommt.

 

[olistudent]

Ja ist es wohl. Aber meine Frage ging eher in die Richtung: Warum tritt das Problem jetzt auf? Die uClibc Config hat seit 3 Jahren, diese Optionen so gesetzt.
http://trac.freetz.org/browser/trunk/toolchain/make/target/uclibc/Config.mod_26.0.9.29?rev=1094

Gruß
Oliver