Thema: Projekt von R32: skynet für Linux

[tonno]

Danke, da muss ich nicht mehr selber danach suchen

[spoke1]

Bitte bitte, für sowas gibt es ja dieses muggelige Forum. 

[R32]

Unter h++p://rapidshare.com/files/5818890/skynetR32_1.23beta_Linux.rar habe ich die beta Version der 1.23 für Linux abgelegt. Die beiden files im RAR bitte in das Verzeichnis der Version 1.21 für Linux entpacken.

Möchte mal jemand testen und mir sagen ob es nun läuft und sich die Nachtschicht evtl. gelohnt hat?

Bis morgen,
R32

[amin]

Vielen Dank für die Linux-Version.
Seht so aus, dass du den Bug gefunden hast.

[192e-freak]

Seht so aus, dass du den Bug gefunden hast.

wirklich?

Erstmal danke an R32, dass er sich wieder einmal für die linux community geopfert hat!

Aber bisher konnte ich keinen wirklich großen unterschied zur 1.21 feststellen!
Bisher habe ich es nicht geschafft die 1.23beta länger als 1 minute laufen zu lassen. ;(
Ich bekomme immernoch den "Segmentation fault (core dumped)" fehler.

[spoke1]

@192e-freak

Hast Du die Libaries auch getauscht??

@R32
Ich mach mich da nachher selbstverständlich auch mal dran.

[192e-freak]

@192e-freak

Hast Du die Libaries auch getauscht??

ja, habe ich (habe die original libs vom ubuntu rausgeschmissen und die aus dem skynet paket an deren stelle kopiert)!
Jetzt warte ich erst einmal auf das feedback von anderen usern.

Vielleicht habe ich ja doch etwas nicht beachtet. Bin mal gespannt, ob es bei dir läuft, spoke1!

[amin]

Ich habe lib nicht getauscht, link von lib die ich nutze ist oben.

[mtron]

ich teste auch grad die beta mit der standard lib meiner distro (seit 2 stundenmit save_segments = false, http = true, nntp = false, use_udp = false). scheint gut zu funktionieren (wie bei mir auch die 1.21)

[spoke1]

Bis jetzt rennt das hier. In meinem System sind die Lib's von mtron aktiv, meine hab ich verbummelt. 

mtron's = h**p://rapidshare.com/files/5891495/libpcre.so.html

Somit hat die Nachtschicht Sinn gemacht 

Interessant wird es wenn ich von 32 Bit auf 64 Bit Mandriva wechsle. Bin gespannt wie sich die "Geschichte" dann benimmt.

[192e-freak]

ok, ich habe jetzt einmal den kompletten skynet ordner gelöscht und neu "installiert" (entpackt ).
Und siehe da, bis jetzt kein Absturz!!!

Da bin ich mal gespannt wie lange das rennt (wenn ich die 12h schaffe bin ich zufrieden)!

Nochmal Danke an R32

[amin]

Wenn ich Real Name in skynet.ini aktiviere, segfault 1.31bete weiter.
Ich denke die änderungen in code könnten helfen.
In funktion generate_name

Code: [Auswählen]

for(; *format; ++format)
{
if( l<1 )//sonst buffer überlauf
break;
switch(*format)
In Funktion nntp_start

Code: [Auswählen]

r_id = file_add(c, 0, tcp_timeout, "", "", "nntp", buff, 0);//"" oder was auch immer statt 0

Hier mein diff für cache.cpp 0.91 version

Code: [Auswählen]

--- cache.cpp 2005-11-23 13:11:00.000000000 +0100
+++ cache.cpp 2006-11-22 15:31:28.000000000 +0100
@@ -175,7 +218,8 @@
  }
  else if(x->o == fo::MOVE)
  { char* from = x->d.begin()->d;
- char* to = from + strlen(from) + 1;
+ int fromlen=(from==NULL)?0:strlen(from);
+ char* to = from + fromlen + 1;
  if(*to)
  { if(rename(from, to))
  { make_directory(to);
@@ -241,13 +284,14 @@
 }
 
 int cache_open(const char* name)
-{ int h = vh();
+{
+ int h = vh();
  fo x;
  x.h = h;
  x.o = fo::OPEN;
  x.t = time();
-
- block b = { 0, strcpy(new char[strlen(name)+1], name), 0 };
+ int namelen=(name==NULL)?0:strlen(name)+1;
+ block b = { 0, strncpy(new char[namelen], name,namelen), 0 };
  x.d.push_back(b);
 
  cache_lock();
@@ -257,13 +301,15 @@
 }
 
 int cache_create(const char* name)
-{ int h = vh();
+{
+ int h = vh();
  fo x;
  x.h = h;
  x.o = fo::CREATE;
  x.t = time();
+ int namelen=(name==NULL)?0:strlen(name)+1;
 
- block b = { 0, strcpy(new char[strlen(name)+1], name), 0 };
+ block b = { 0, strncpy(new char[namelen], name,namelen), 0 };
  x.d.push_back(b);
 
  cache_lock();
@@ -307,13 +353,13 @@
  x.t = time();
 
  if(from && to)
- { int l1 = strlen(from) + 1;
- int l2 = strlen(to) + 1;
+ { int l1 = (from==NULL)?0:strlen(from) + 1;
+ int l2 = (to==NULL)?1:strlen(to) + 1;
 
  block b;;
- b.d = new char[l1+l2];
- strcpy(b.d, from);
- strcpy(b.d + l1, to);
+ b.d = new char[l1+l2+1];
+ strncpy(b.d, from,l1);
+ strncpy(b.d + l1, to,l2);
 
  x.d.push_back(b);
  }
@@ -328,11 +374,11 @@
  x.o = fo::MKDIR;
  x.t = time();
 
- int l = strlen(name) + 1;
+ int l = (name==NULL)?1:strlen(name) + 1;
 
  block b;;
  b.d = new char[l];
- strcpy(b.d, name);
+ strncpy(b.d, name,l);
 
  x.d.push_back(b);
 
und kosmetik für name.
In File util.cpp

Code: [Auswählen]

string safe(const string& a)
{
string r = a;

for(size_t i = 0; i < a.length(); ++i)
{
if(r[i] >= 0 && r[i] < ' ') r[i] = '_';
switch(r[i])
{
case '\\':
case '/':
case ':':
case '*':
case '?':
case '"':
case '<':
case '>':
case '|':
r[i] = '_';
break;
case '%'://%20 usw weg
if(r.length()-i>2)
r.replace(i,3,"_");
else
r[i] = '_';
break;
}
}
return r;
}



[spoke1]

Nochmal zu der Lib - Geschichte:

ich hab es nun endlich mal geschafft meinen x64 Rechner auch mit dem entsprechendem Linux zu versehen.
Kanditat hierfür: Mandiva 2007_X64.

skynetŔ32 1.23 lief (wundersamer Weise) aus dem Stand heraus. Somit sollte dem Linux DL nach Möglichkeit einige der funktionierenden Lib's beigefügt bzw. mit auf die HP gepackt werden. Ich werde diese hier jetzt kopieren und gut wegpacken.
Dann muß ich leider auf die 32Bit Version zurück, da ein ganzer Rattenschwanz an Programmen (u. a. kaffeine) sich weigert Java, qt3 etc. zu finden, da es sich bei diesen Programmen ja nicht um X64 Architekturen handelt (somit falsches verlinken von libaries). Es besteht sicher die Möglichkeit das händisch im ./configure zu fixen, dafür fehlt mir aber erstens das Wissen und zweitens die Zeit.

Derzeitige Schlussfolgerung: sich eine 64Bit Maschine zuzulegen macht in meinen Augen wenig Sinn. Weder unter M$ noch mdv bin ich mit den jeweiligen 64Bit BS glücklich geworden. Und mit halber Kraft zu fahren war eigentlich nicht Sinn der Anschaffung. Das kommt dabei raus wenn man sich vorher nicht vernünftig informiert.  Steckt anscheinend immer noch alles in den Kinderschuhen, die Entwicklung der Soft lässt weiter auf sich warten. Offensichtlich sind 64Bit Systeme nicht verbreitet genug und es besteht daher kein Interesse auf diesen Zug mit aufzuspringen??

Bleibt nun abzuwarten wie der Mod sich nach der Neuinstallation der 32 Bit Version mit den originalen Lib's verhält.

Ich werde berichten.

Gruß, spoke1

[amin]

//OT
Ich fahre hier mit gentoo 64bit und ich kann nicht klagen.

[Dragonix]

also ich hab mit gentoo64 und suse 64 egtl auch keine probleme gehabt...