[Patch] NZBGet

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Jepp, was mich nur wundert:
Code: 
bool Util::ForceDirectories(const char* szPath)
{
	char* szNormPath = strdup(szPath);
[...]
Das lese ich so:
szPath ist ein konstanter String, für den zunächst mal in szNormPath eine Kopie angelegt ist. Der einzige weitere Aufruf mit szPath ist der strlen Befehl.

Da in szNormPath ein Wert ist, müsste m.E. szPath beim Aufruf "ungleich 0x0" zu sein, oder sehe ich das verkehrt?
 
So sollte es sein, aber der Debugger sagt, das der Wert 0 ist. Es kann sein, das der Compiler beim Optimieren Anweisungen durcheinander schiebt. Vielleicht wird auch in strdup auf NULL geprüft.

Du kannst versuchen, im Debugger einen Breakpunkt auf den Anfang der Funktion zu setzen.
Und Du kannst mal versuchen, die Datei ohne Optimierung zu übersetzen.
 
Dann ist die eine Lib (bzw. deren strlen()) NULL-Pointer-Safe und die andere nicht, uU. sind dann im Code mehrere solcher Bomben versteckt.

EDIT: Beitrag kam zu spät und lag wohl daneben ;)
 
So mit Breakpoints habe das ganze etwas weiter eingegrenzt (In Util.cpp 257 bei 0.8.0-testing):
Code: 
	printf ("Vor S_ISDIR szPath=%s\n",szPath);	
	bool bOK = !stat(szNormPath, &buffer) && S_ISDIR(buffer.st_mode);
	printf ("Nach S_ISDIR szPath=%s\n",szPath);
Ergibt beim Aufruf:
Code: 
root@Speedport:/var/tmp# ./nzbget -c nzbget.conf  hallo
Nach S_ISDIR szPath=/var/tmp/download/dst/
Nach S_ISDIR szPath=/var/tmp/download/dst/
mytemp=/var/tmp/download
Nach S_ISDIR szPath=/var/tmp/download
Nach S_ISDIR szPath=/var/tmp/download
mytemp=/var/tmp
Nach S_ISDIR szPath=/var/tmp
Nach S_ISDIR szPath=(null)
Segmentation fault
root@Speedport:/var/tmp# ./nzbget -c nzbget.conf  hallo
Vor S_ISDIR szPath=/var/tmp/download/dst/
Nach S_ISDIR szPath=/var/tmp/download/dst/
Vor S_ISDIR szPath=/var/tmp/download
Nach S_ISDIR szPath=/var/tmp/download
Vor S_ISDIR szPath=/var/tmp
[B]Nach S_ISDIR szPath=(null)
[/B]Segmentation fault
root@Speedport:/var/tmp#

Gehe weiter rein...

EDIT
Die Veränderung passiert in
Code: 
stat(szNormPath, &buffer)
Als Ergebnis von dem Trennen der beiden per && verbundenen Teile in der Zeile " bool bOK = ...":

Code: 
	struct stat buffer;
	printf ("Vor S_ISDIR szPath=%s\n",szPath);
	bool stat_bool=stat(szNormPath, &buffer);
	printf ("Nach stat szPath=%s\n",szPath);
	bool isdir_bool=S_ISDIR(buffer.st_mode);
	printf ("Nach isdir szPath=%s\n",szPath);
	bool bOK = !stat_bool && isdir_bool;
	if (!bOK

Code: 
root@Speedport:/var/tmp# ./nzbget -c nzbget.conf  hallo
Vor S_ISDIR szPath=/var/tmp/download/dst/
Nach stat szPath=/var/tmp/download/dst/
Nach isdir szPath=/var/tmp/download/dst/
Vor S_ISDIR szPath=/var/tmp/download
Nach stat szPath=/var/tmp/download
Nach isdir szPath=/var/tmp/download
Vor S_ISDIR szPath=/var/tmp
Nach stat szPath=(null)
Nach isdir szPath=(null)
Segmentation fault
root@Speedport:/var/tmp#

Jetzt bin ich aber am Ende...
 
Zuletzt bearbeitet:
Hast Du es mal ohne Optimizer versucht (-O0)?
 
Das komplette Binary ist hier mit "-O0 -g" übersetzt. Könnte wenn nur von den "normal" gelinkten Libs kommen, denke ich??
Jetzt brauchen wir echte Experten ;-)

Jörg
 
Da müsste man in den Assemblercode wohl reingucken, was an der Stelle nun passiert.
Hast Du mal versucht das Ergebnis von strlen(szPath) zu "cachen"? Ist ja mit jedem Schleifendurchlauf identisch...
Man könnte wohl "iLen" statt strlen() dazu nehmen.
 
Ja, (statt "strlen(szPath)" den oben schonmal berechneten Wert "iLen" genutzt), hilft aber nix, dann steigt es an anderer Stelle aus, das scheint irgendwie nur eines von mehreren Problemen zu sein...

Mal im Vergleich "mein" Binary und das mipsel-Binary von der nzbget-Seite. Meines (mit "iLen"):
Code: 
root@Speedport:/var/tmp# strace ./nzbget -c nzbget.conf  hallo
execve("./nzbget", ["./nzbget", "-c", "nzbget.conf", "hallo"], [/* 209 vars */]) = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
[...]
close(3)                                = 0
stat64("/var/tmp/download/dst", 0x7fa96260) = -1 ENOENT (No such file or directory)
stat64("/var/tmp/download", 0x7fa961c0) = -1 ENOENT (No such file or directory)
stat64("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=0, ...}) = 0
stat64("/var", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat64("", 0x7fa95fe0)                  = -1 ENOENT (No such file or directory)
mkdir("", 0777)                         = -1 ENOENT (No such file or directory)
stat64("", 0x7fa95fe0)                  = -1 ENOENT (No such file or directory)
--- {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} (Segmentation fault) ---
+++ killed by SIGSEGV +++
Segmentation fault
root@Speedport:/var/tmp#

Und dazu das statisch gelinkte Binary von der Homepage:
Code: 
root@Speedport:/var/tmp# strace ./nzbget_static  -c nzbget.conf  hallo
execve("./nzbget_static", ["./nzbget_static", "-c", "nzbget.conf", "hallo"], [/* 209 vars */]) = 0
ioctl(0, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
[...]
close(3)                                = 0
stat("/var/tmp/download/dst", 0x7fdc6250) = -1 ENOENT (No such file or directory)
stat("/var/tmp/download", 0x7fdc6188)   = -1 ENOENT (No such file or directory)
stat("/var/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=0, ...}) = 0
mkdir("/var/tmp/download", 0777)        = 0
stat("/var/tmp/download", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
mkdir("/var/tmp/download/dst", 0777)    = 0
stat("/var/tmp/download/dst", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/var/tmp/download/tmp", 0x7fdc6250) = -1 ENOENT (No such file or directory)
stat("/var/tmp/download", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
mkdir("/var/tmp/download/tmp", 0777)    = 0
stat("/var/tmp/download/tmp", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/var/tmp/download/queue", 0x7fdc6250) = -1 ENOENT (No such file or directory)
stat("/var/tmp/download", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
mkdir("/var/tmp/download/queue", 0777)  = 0
stat("/var/tmp/download/queue", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
stat("/var/tmp/download/nzb", 0x7fdc6250) = -1 ENOENT (No such file or directory)
stat("/var/tmp/download", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
mkdir("/var/tmp/download/nzb", 0777)    = 0
stat("/var/tmp/download/nzb", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
getcwd("/var/tmp", 1024)                = 9
brk(0x820000)                           = 0x820000
brk(0x823000)                           = 0x823000
brk(0x825000)                           = 0x825000
brk(0x826000)                           = 0x826000
brk(0x828000)                           = 0x828000
rt_sigaction(SIGINT, {0x10000000, [RT_69 RT_71 RT_72 RT_74 RT_75 RT_76 RT_78 RT_80 RT_83 RT_84 RT_85 RT_86 RT_87], 0x580704 /* SA_??? */}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGTERM, {0x10000000, [RT_69 RT_71 RT_72 RT_74 RT_75 RT_76 RT_78 RT_80 RT_83 RT_84 RT_85 RT_86 RT_87], 0x580704 /* SA_??? */}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGCHLD, {0x10000000, [RT_69 RT_71 RT_72 RT_74 RT_75 RT_76 RT_78 RT_80 RT_83 RT_84 RT_85 RT_86 RT_87], 0x580704 /* SA_??? */}, {SIG_DFL, [], 0}, 16) = 0
rt_sigaction(SIGPIPE, {0x10000000, [], SA_NOCLDSTOP}, {SIG_DFL, [RT_68 RT_75 RT_77 RT_79 RT_80 RT_81 RT_83 RT_84 RT_86 RT_87], 0}, 16) = 0
brk(0x829000)                           = 0x829000
time(NULL)                              = 946694413
brk(0x82a000)                           = 0x82a000
ioctl(1, TIOCNXCL, {B38400 opost isig icanon echo ...}) = 0
stat64("/mod/root/.terminfo", 0x7fdc55e8) = -1 ENOENT (No such file or directory)
stat64("/opt/share/terminfo", 0x7fdc55e8) = -1 ENOENT (No such file or directory)
write(2, "Error opening terminal: ", 24Error opening terminal: ) = 24
write(2, "xterm", 5xterm)                    = 5
write(2, ".\n", 2.
)                      = 2
exit(1)                                 = ?
root@Speedport:/var/tmp#
 
Zuletzt bearbeitet:
Abgesehen davon, dass der Stil der Funktion teilweise etwas eigen ist, ist das Speichern des Wertes von strlen zwar gut für den Stil und die Geschwindigkeit der Ausführung, aber keine Lösung für das eigentliche Problem.

So wie es aussieht, ist die Struktur stat zu klein definiert.
Kannst Du im Programm vor dem Aufruf von stat noch folgendes einbauen:
Code: 
printf ("buffer %p, szPath %p, size %d, diff %d\n", &buffer, &szPath, sizeof (buffer), (char *)&szpath - (char *)&buffer);
Vor gar nicht so langer Zeit hatten wir hier einen Thread, wo angeblich die Funktion stat nicht richtig funktioniert hätte. Da war es auch ein Problem mit der Definition der Struktur stat.

Wie man am strace sehen kann, wird die Funktion stat64 aufgerufen, aber wahrscheinlich eine 32-Bit stat Struktur verwendet (was normalerweise nicht passieren darf).
 
Ich war von einen Fehler in der Codegenerierung ausgegangen, nachdem ich jetzt mal in den Asm Code geguckt habe, kam ich zu dem Schluss, daß der Stack überschrieben wird.
 
@Ralf: Jetzt sieht das so aus:

Code: 
	struct stat buffer;
	printf ("buffer %p, szPath %p, size %d, diff %d\n", &buffer, &szPath, sizeof (buffer), (char *)&szPath - (char *)&buffer);
	printf ("Vor S_ISDIR szPath=%s\n",szPath);
	bool stat_bool=stat(szNormPath, &buffer);
	printf ("Nach stat szPath=%s\n",szPath);
	bool isdir_bool=S_ISDIR(buffer.st_mode);
	printf ("Nach isdir szPath=%s\n",szPath);
	bool bOK = !stat_bool && isdir_bool;
	if (!bOK
[...snipp...]
				*p = '\0';
			}
			if (strlen(szParentPath) [B]!= iLen[/B])
			{
				bOK = ForceDirectories(szParentPath);
			}

Mit diesem Ergebnis (jetzt ist szPath gleich nach dem ersten Aufruf schon "null" ?!?)
Code: 
root@Speedport:/var/tmp# ./nzbget -c nzbget.conf  hallo
buffer 0x7ffcf318, szPath 0x7ffcf378, size 88, diff 96
Vor S_ISDIR szPath=/var/tmp/download/dst/
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7ffcf280, szPath 0x7ffcf2e0, size 88, diff 96
Vor S_ISDIR szPath=/var/tmp/download
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7ffcf1e8, szPath 0x7ffcf248, size 88, diff 96
Vor S_ISDIR szPath=/var/tmp
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7ffcf150, szPath 0x7ffcf1b0, size 88, diff 96
Vor S_ISDIR szPath=/var
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7ffcf0b8, szPath 0x7ffcf118, size 88, diff 96
Vor S_ISDIR szPath=
Nach stat szPath=
Nach isdir szPath=
Segmentation fault
root@Speedport:/var/tmp#

EDIT Ach so, auch die "strlen" Werte überhaupt waren an dieser Stelle etwas "merkwürdig" (so in der Größenordnung von 7 MIllionen oder so) , ich hatte die mal mit ausgeben lassen, hänge ich gleich noch an...

Hatte ich noch im Puffer ;-) Die Längen "vor" *p = '\0' (prelen_xx ) und danach (len_xx ) sind schon merkwürdig, oder??

Code: 
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x400 (LWP 1026)]
0x006180f4 in strlen ()
(gdb) bt full
#0  0x006180f4 in strlen ()
No symbol table info available.
#1  0x0046c5b0 in Util::ForceDirectories (szPath=0x0) at Util.cpp:278
	szParentPath = 0x6f9760 "/mod/root"
	p = 0x6f9764 "/root"
	szNormPath = 0x6fa998 "/mod/root"
[B]	len_szpath = 0
	len_stparentpath = 0
	prelen_szpath = 6409520
	prelen_stparentpath = 7313224
[/B]	iLen = 9
	buffer = {st_dev = 11, __pad1 = 0, __st_ino = 0, st_mode = 546, st_nlink = 0, st_uid = 16877, st_gid = 2, st_rdev = 0, __pad2 = 0, st_size = 0, 
  st_blksize = 0, st_blocks = 1311681166, st_atim = {tv_sec = 1311681166, tv_nsec = 0}, st_mtim = {tv_sec = 946684805, tv_nsec = 500000000}, st_ctim = {
    tv_sec = 4096, tv_nsec = 0}, st_ino = 0}
	bOK = true
#2  0x00000000 in ?? ()
No symbol table info available.
(gdb) quit
 
Zuletzt bearbeitet:
@MaxMuster
Die Größe von struct stat (88) bei Dir ist extrem klein.
Ich habe mit -D_FILE_OFFSET_BITS=32 152 und mit -D_FILE_OFFSET_BITS=64 160. Da bei Dir stat64 aufgerufen wird, brauchst Du 160 Bytes. Kein Wunder, dass danach einiges überschrieben wird.
 
Kann ich das irgendwie beeinflussen oder "kaputt gemacht" haben? Und wenn, wie?

EDIT: Moment, ich hatte eben (nach dem Vergleich mit dem "fertigen" Binary) im Makefile alle "64-er" Optionen rausgenommen. Ich baue gerade nochmal, das könnte daran liegen...

So, nochmal gebaut, mit diesem Aufruf:
Code: 
mipsel-linux-uclibc-g++-wrapper  -march=4kc -O0 -g -pipe -Wa,--trap [B]-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64[/B]  -L/ramdisk/freetz-stable-1.2/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/usr/lib -lpthread -lz -lm -lxml2   -L/usr/lib -L/ramdisk/freetz-stable-1.2/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/usr/lib -lsigc-2.0   -L/usr/lib -L/usr/lib -o nzbget  ArticleDownloader.o BinRpc.o ColoredFrontend.o Connection.o Decoder.o DiskState.o DownloadInfo.o Frontend.o Log.o LoggableFrontend.o NCursesFrontend.o NNTPConnection.o NZBFile.o NetAddress.o NewsServer.o Observer.o Options.o ParChecker.o PrePostProcessor.o QueueCoordinator.o QueueEditor.o RemoteClient.o RemoteServer.o Scanner.o Scheduler.o ScriptController.o ServerPool.o svn_version.o TLS.o Thread.o Util.o XmlRpc.o nzbget.o  -lssl -lpar2 -lncurses -lpthread

Ergebnis ist etwas anders, aber noch immer nicht, wie bei dir:

Code: 
root@Speedport:/var/tmp# ./nzbget -c nzbget.conf  hallo
buffer 0x7fae7308, szPath 0x7fae7378, size 104, diff 112
Vor S_ISDIR szPath=/var/tmp/download/dst/
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7fae7260, szPath 0x7fae72d0, size 104, diff 112
Vor S_ISDIR szPath=/var/tmp/download
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7fae71b8, szPath 0x7fae7228, size 104, diff 112
Vor S_ISDIR szPath=/var/tmp
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7fae7110, szPath 0x7fae7180, size 104, diff 112
Vor S_ISDIR szPath=/var
Nach stat szPath=(null)
Nach isdir szPath=(null)
buffer 0x7fae7068, szPath 0x7fae70d8, size 104, diff 112
Vor S_ISDIR szPath=
Nach stat szPath=
Nach isdir szPath=
Segmentation fault
root@Speedport:/var/tmp#

EDIT2:
Habe jetzt einen frisch ausgecheckten Trunk genommen und bekomme wieder "88" als Größe:
Code: 
root@Speedport:/var/tmp# ./nzbget_trunk  -c nzbget.conf  hallo
buffer 0x7fb59300, szPath 0x7fb59368, size 88, diff 104
Vor S_ISDIR szPath=/var/tmp/download/dst/
Nach stat szPath=(null)
Nach isdir szPath=(null)
Segmentation fault
root@Speedport:/var/tmp#
 
Zuletzt bearbeitet:
Was kommt bei Dir mit diesem Kommando heraus?
Code: 
echo '#include <sys/stat.h>' | mipsel-linux-uclibc-g++ -x c++ -E /dev/stdin | sed -ne '/^struct stat/,/\}\;/p'  | less
Was mit mipsel-linux-uclibc-g++-wrapper statt dessen?

Bei mir sieht es so aus:
Code: 
struct stat
  {
 __dev_t st_dev;
    long int st_pad1[2];

    __ino_t st_ino;

    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;

    long int st_pad2[1];
    __off_t st_size;

    long int st_pad3;
# 68 ".../include/bits/stat.h" 3
    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;

    __blkcnt_t st_blocks;

    long int st_pad5[14];
  };
struct stat64
  {
    __dev_t st_dev;
    long int st_pad1[2];
    __ino64_t st_ino;
    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;
    long int st_pad2[2];
    __off64_t st_size;

    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;
    long int st_pad3;
    __blkcnt64_t st_blocks;
    long int st_pad4[14];
  };
 
Bei beiden Aufrufen das gleiche, bis auf den Pfad identisch zu deinem Output?!?
Code: 
joerg@joerg-desktop:/ramdisk/freetz-trunk$ echo '#include <sys/stat.h>' | mipsel-linux-uclibc-g++ -x c++ -E /dev/stdin | sed -ne '/^struct stat/,/\}\;/p' 
struct stat
  {
 __dev_t st_dev;
    long int st_pad1[2];

    __ino_t st_ino;



    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;

    long int st_pad2[1];
    __off_t st_size;

    long int st_pad3;
# 68 "/ramdisk/freetz-trunk/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/bits/stat.h" 3
    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;

    __blkcnt_t st_blocks;




    long int st_pad5[14];
  };
struct stat64
  {
    __dev_t st_dev;
    long int st_pad1[2];
    __ino64_t st_ino;
    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;
    long int st_pad2[2];
    __off64_t st_size;




    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;
    long int st_pad3;
    __blkcnt64_t st_blocks;
    long int st_pad4[14];
  };
joerg@joerg-desktop:/ramdisk/freetz-trunk$ echo '#include <sys/stat.h>' | mipsel-linux-uclibc-g++-wrapper -x c++ -E /dev/stdin | sed -ne '/^struct stat/,/\}\;/p' 
struct stat
  {
 __dev_t st_dev;
    long int st_pad1[2];

    __ino_t st_ino;



    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;

    long int st_pad2[1];
    __off_t st_size;

    long int st_pad3;
# 68 "/ramdisk/freetz-trunk/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/bits/stat.h" 3
    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;

    __blkcnt_t st_blocks;




    long int st_pad5[14];
  };
struct stat64
  {
    __dev_t st_dev;
    long int st_pad1[2];
    __ino64_t st_ino;
    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;
    long int st_pad2[2];
    __off64_t st_size;




    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;
    long int st_pad3;
    __blkcnt64_t st_blocks;
    long int st_pad4[14];
  };
 
Dann versuche mal das Gleiche mit der Aufruf der Util.cpp.
Die Option -E bewirkt, dass die Ausgabe nach stdout geht, Die Option "-x c++" braucht man nicht, wenn die Datei schon die Endung .cpp hat.

Es muss ja einen Grund haben, dass beim Übersetzen der Datei die Struktur soviel kleiner ist.
 
Das sieht jetzt anders aus, ich denke, dir sagt das was ;-)

Code: 
joerg@joerg-desktop:/ramdisk/freetz-stable-1.2/source/target-mipsel_uClibc-0.9.29/nzbget-0.8.0-testing$ mipsel-linux-uclibc-g++ -E Util.cpp | sed -ne '/^struct stat/,/\}\;/p' 
struct stat
  {
 __dev_t st_dev;
    long int st_pad1[2];

    __ino_t st_ino;



    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;

    long int st_pad2[1];
    __off_t st_size;

    long int st_pad3;
# 68 "/ramdisk/freetz-stable-1.2/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/bits/stat.h" 3
    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;

    __blkcnt_t st_blocks;




    long int st_pad5[14];
  };
struct stat64
  {
    __dev_t st_dev;
    long int st_pad1[2];
    __ino64_t st_ino;
    __mode_t st_mode;
    __nlink_t st_nlink;
    __uid_t st_uid;
    __gid_t st_gid;
    __dev_t st_rdev;
    long int st_pad2[2];
    __off64_t st_size;




    __time_t st_atime;
    unsigned long int st_atimensec;
    __time_t st_mtime;
    unsigned long int st_mtimensec;
    __time_t st_ctime;
    unsigned long int st_ctimensec;
    __blksize_t st_blksize;
    long int st_pad3;
    __blkcnt64_t st_blocks;
    long int st_pad4[14];
  };
struct statvfs
  {
    unsigned long int f_bsize;
    unsigned long int f_frsize;

    __fsblkcnt_t f_blocks;
    __fsblkcnt_t f_bfree;
    __fsblkcnt_t f_bavail;
    __fsfilcnt_t f_files;
    __fsfilcnt_t f_ffree;
    __fsfilcnt_t f_favail;
# 48 "/ramdisk/freetz-stable-1.2/toolchain/build/mipsel_gcc-4.4.6_uClibc-0.9.29/mipsel-linux-uclibc/bin/../lib/gcc/mipsel-linux-uclibc/4.4.6/../../../../mipsel-linux-uclibc/include/bits/statvfs.h" 3
    unsigned long int f_fsid;

    int __f_unused;

    unsigned long int f_flag;
    unsigned long int f_namemax;
    int __f_spare[6];
  };
struct statvfs64
  {
    unsigned long int f_bsize;
    unsigned long int f_frsize;
    __fsblkcnt64_t f_blocks;
    __fsblkcnt64_t f_bfree;
    __fsblkcnt64_t f_bavail;
    __fsfilcnt64_t f_files;
    __fsfilcnt64_t f_ffree;
    __fsfilcnt64_t f_favail;
    unsigned long int f_fsid;

    int __f_unused;

    unsigned long int f_flag;
    unsigned long int f_namemax;
    int __f_spare[6];
  };
joerg@joerg-desktop:/ramdisk/freetz-stable-1.2/source/target-mipsel_uClibc-0.9.29/nzbget-0.8.0-testing$

Ach nee, das ist nur "statvfs" zusätzlich...

EDIT: Sorry, ich muss mich jetzt erstmal ausklinken, mache aber demnächst gerne weiter, wenn du mir sagst, wo und wie ich noch was tun kann ;-)

Jörg
 
Zuletzt bearbeitet:
Das folgende Programm gibt bei mir auch 152 und 160 aus:

#include <sys/stat.h>
#include <stdio.h>

int main(void)
{
printf("%ld %ld\n", sizeof(struct stat), sizeof(struct stat64));
return 0;
}
 
Und zum wiklichen Schluss für heute: Bei mir auch, es ist zum Verzweifeln
(gebaut mit "mipsel-linux-uclibc-g++-wrapper -static mytest.cpp -o mytest"):
Code: 
root@Speedport:/var/tmp# ./mytest 
152 160
root@Speedport:/var/tmp#
 
  1. Alle Zeilen in nzbget.mk, die CXXFLAGS enthalten, löschen. Mit anderen Worten CXXFLAGS nicht überladen. Zum einen ist die Überladung fehlerhaft, was dazu führt, dass die LFS-Flags
    -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
    verschwinden, zum anderen ist die Überladung überflüssig.
  2. Folgende Zeile in nzbget.mk hinzufügen:
    $(PKG)_CONFIGURE_ENV += LIBPREF="$(TARGET_TOOLCHAIN_STAGING_DIR)/usr"
    (es hat noch nie zu was gutem geführt host-includes mit target-includes zu mischen)
  3. config.cache löschen
  4. make nzbget-clean
  5. make nzbget-precompiled
  6. testen und berichten, ich hab's auf der Box nicht getestet

p.s. würde man mytest.cpp mit den o.g. LFS-Flags übsersetzen, so müssten die beiden Größen übereinstimmen.

p.p.s. und falls Ihr möchtet, dass das Paket in trunk aufgenommen wird, so würde ich euch bitten, eine Lösung zu finden, bei der keine Überladung von LDADD notwendig ist oder zumindest deutlich weniger Libraries explizit angegeben werden müssen. Und es muss sowohl mit uClibc++ als auch mit libstdc++ funktionieren.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 776 (Mitglieder: 37, Gäste: 739)

Neueste Beiträge

Statistik des Forums

Themen
246,157
Beiträge
2,247,048
Mitglieder
373,675
Neuestes Mitglied
Stefan2000
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück