Dart auf Webhosting4000 ausführen

  • Hallo,


    Da das Webhosting4000 erlaubt, einige Scripte auf der Kommandozeile auszuführen, wollte ich mal versuchen das Dart SDK dort zum laufen zu bringen. Nach ewigen hin und her, scheitere ich nun an folgenden Fehler :

    Code
    /httpdocs/tmp/bin/dart /httpdocs/testproject/bin/main.dart 
    ../../runtime/vm/os_thread.cc: 47: error: Failed to retrieve stack bounds

    Nach Rücksprache mit anderen Entwicklern, vermuten wir, dass es eine Limitierung in den Webhosting4000 Paket bzw. mit den Linux Usern die hier das Problem verursachen.


    Gibt es bekannte Einschränkungen, wenn man mit einem Webhosting4000 Paket, bei einem Script auf die Betriebssystem Threads zugreifen will ?


    Grüße

  • Die Shell im Webhosting-Paket ist eigentlich nur als Management-Interface zum Dateien 'rumschubsen' sowie php-Cronjobs gedacht. Auf das Betriebssystemsystem solltest du in einem PHP-Webhosting-Paket keinerlei Zugriff haben. Dafür gibt es (managed) vServer.


    Was genau ist dart? Das sieht für mich aus wie ein Tomcat, der viel Speicher und Netzwerkports braucht.

    "Security is like an onion - the more you dig in the more you want to cry"

  • Was genau ist dart? Das sieht für mich aus wie ein Tomcat, der viel Speicher und Netzwerkports braucht.

    Wie Nitram schon richtig erwähnt hat ist Dart eine Programmiersprache die hauptsächlich von Google entwickelt wird. Der große Vorteil daran ist, dass diese multiplattform fähig ist und seit kurzen das compilieren in native, allein lauffähige Binärdateien erlaubt, die das SDK selber enthalten.


    Grundsätzlich ist das von mir blos eine Idee gewesen ob es evtl. funktionieren würde eine solche Datei auf den Server auszuführen. Dabei bin ich auf das von mir genannte Problem gestoßen und habe versucht das SDK direkt auf den Server auszuführen, was wegen den oben genannten Fehler scheitert.


    Ich bin noch dabei herauszufinden ob es sich hierbei um einen Fehler im SDK handelt oder das Problem hier der Server ist. Ist Zweiteres der Fall, so ist das kein Problem.


    Aber wäre eine super Sache wenn Dart allgemein verfügbar wäre da ja z.B. Node.js auch unterstützt wird und für Dart auch entsprechende Debian Pakete existieren.


    Grüße

  • Die node.js Unterstützung ist auch nicht so toll wie es klingt :rolleyes:. In welcher Form müsstest Du denn auf die Threads des Systems zugreifen?

    Das ist eine gute Frage! Grundsätzlich habe ich bisher nur herausgefunden, das ein bestimmtes C++ Script aufgerufen wird was wohl irgendwas mit den Threads des Systems macht. Da ich mich in C++ nicht auskenne, komm ich hier aktuell nicht weiter und warte auf Rückmeldung auf Github.


    Vermutlich verursacht dieser Stück Code das Problem ( Zeile 4 oder 10 müssten entscheidend sein ) :

    Die folgenden "Funktionen" scheinen irgendetwas mit Threads zu machen.

    Code
    pthread_getattr_np()
    pthread_attr_getstack()
  • Ein kleines Update von Google (https://github.com/dart-lang/sdk/issues/40405) : Es scheint so als würde in den oben genannten Codezeilen versucht zu werden auf eine Datei unterhalb /proc/self/maps zugreifen zu wollen.


    Eine Erklärung zu dieser Datei : https://stackoverflow.com/ques…anding-linux-proc-id-maps


    Da der Pfad bzw. die Datei aktuell nicht existiert, bzw. der Shell User selber keine solche Datei hat, scheint das aktuell nicht zu klappen.


    Hat hier jemand noch eine Idee ?

  • Also ich denk mal... da der Pfad nicht in open_basedir freigegeben wird, kann man halt nicht darauf zugreifen. Da wird netcup wahrscheinlich auch nichts dran ändern. Aber fragen kostet nichts, also vielleicht mal ein Support-Ticket aufmachen.

  • Also ich denk mal... da der Pfad nicht in open_basedir freigegeben wird, kann man halt nicht darauf zugreifen.

    open_basedir ist eine PHP Sicherheitseinstellung und hat recht wenig mit dem Ausführen von Executables zu tun.


    Script auf die Betriebssystem Threads zugreifen will ?

    Die Basis von solchen POSIX Threads ist libpthread.so, die erst von dem Programm vom Betriebssystem geladen werden muss.

    Da du hier keinen vollständigen Linux Unterbau hast, sondern nur eine SSH Schnittstelle, die nicht als POSIX-kompatibel angesehen werden kann, wird das so in der Form auf dem Webhosting nicht funktionieren, und ist auch nicht im Sinne von Netcup.


    Hierfür bräuchtest du einen vServer oder du guckst bspw. mal bei Uberspace. Das sind auf alle Fälle keine Bugs, sondern die Limitierungen des Shared Webhostings.

  • open_basedir ist eine PHP Sicherheitseinstellung und hat recht wenig mit dem Ausführen von Executables zu tun.

    Da hast du freilich recht. Es hat eher gar nichts damit zu tun, weil PHP gar nicht genutzt wird. Uberspace ist wahrscheinlich echt die beste Adresse dafür. Wenn es auf irgendeinem Shared Webhosting funktioniert, dann da. Wobei ich Uberspace jetzt nicht mal unbedingt als Webhosting bezeichnen mag, obwohl es natürlich auch dafür nutzbar ist.