python fehler

[Benutzername123456]

ValueError: Exceeds the limit (4300) for integer string conversion; use sys.set_int_max_str_digits() to increase the limit

[PythonCodingFun]

Schon die Meldung auf Stackoverflow nachgeschlagen ?

https://stackoverflow.com/questions/736 ... g-conversi

[__blackjack__]

Oder einfach mal einen Blick in die Dokumentation werfen was die Funktion, die in der Fehlermeldung vorgeschlagen wird, so macht.

[sparrow]

@Benutzername123456: Bist du dir sicher, dass du mit Zahlen arbeiten willst, die dermaßen viele Stellen haben? Oder ist das der Fehler?

[DeaD_EyE]

ValueError: Exceeds the limit (4300) for integer string conversion; use sys.set_int_max_str_digits() to increase the limit

Stell dir vor, du betreibst einen Webserver mit einer Webanwendung, die mit Python entwickelt worden ist.
Nun hast du irgendeine Unterseite, die einen int als Eingabe erwartet. Wenn der Nutzer nun in der Lage ist, sehr lange Ganzzahlen an die Webanwendung zu senden, kann er damit die Webanwendung mit der Umwandlung der Ganzzahl beschäftigen und wenn das nicht ausreicht, dann schickt man halt ganz viele Requests und die CPU-Last wird dann auf 100% gehen und Requests werden immer langsamer oder gar nicht mehr beantwortet.

[Sirius3]

@DeaD_EyE: es geht eben nicht darum, viele Requests zu schicken, denn das geht ja immer noch. Der Trick bei DoS-Attacken ist es, etwas zu finden, was beim Angreifer linearen Aufwand generiert und beim Angegriffenen über-linearen Aufwand, hier eben O(n²).

[__blackjack__]

@Sirius3: Naja, bei dem mickrigen 4300 Stellen braucht man aber doch ganz viele Requests und die Begründung warum diese Grenze so verdammt niedrig gesetzt wurde war nicht Zeit, sondern weil das die kleinste Zahl war bei der die Numpy-Unittests noch durchlaufen.

[Sirius3]

@__blackjack__: meine Rede, die Grenze wurde so groß wie nötig und so klein wie möglich gesetzt, damit möglichst viele mit den Defaults leben können. In Python <=3.9 gab es diese Grenze nicht, und dort macht es eben einen Unterschied ob ich 1000 Requests mit einer 1000Stelligen Zahl oder einen Request mit einer 1000000Stelligen Zahl abschicke.
Warum wurde das Recursion-Limit auf 1000 gesetzt? Auch eine willkürlich gewählte Grenze.

[__blackjack__]

@Sirius3: Aber bei beiden macht ein Request mit einer 4301 Stellen langen Zahl keinen merklichen Unterschied. Und 1000 eigentlich auch noch nicht.

Das Recursion-Limit stand mal bei 1000 weil Guido da schon die 1000 Stackframes bei der Ausnahme eigentlich schon zu viel fand. Mittlerweile ist es bei 3000. Und es gibt einen Unterschied: statt einfach nur langsamer zu werden crasht ein Programm hart wenn man das Limit zu hoch setzt, und es gibt keinen Weg halbwegs robust tatsächlich ein Limit zu setzen, das den kompletten Stack ausreizt. Auf meinem Rechner scheint das etwas weniger als ein Drittel der Aufrufe zu sein die zu einem Crash führen, allerdings ist da halt nicht garantiert, dass das Testskript auch wirklich den internen Interpreterpfad triggert der für die 10.400 Aufrufe auch tatsächlich die gröstmöglichen Stackframes pro Aufruf erzeugt. Kann also sein, dass es auch bei 10.400 Aufrufen in der Praxis schon einen Segfault geben kann.

[DeaD_EyE]

@DeaD_EyE: es geht eben nicht darum, viele Requests zu schicken, denn das geht ja immer noch. Der Trick bei DoS-Attacken ist es, etwas zu finden, was beim Angreifer linearen Aufwand generiert und beim Angegriffenen über-linearen Aufwand, hier eben O(n²).

Wie ein DoS funktioniert, ist mir bekannt. Die Aussage, dass ein Request nicht ausreicht, stammt von einem Core-Dev. Wenn nur ein Request dazu geführt hätte, hätte man schon viel eher den Patch rausgebracht. Soweit ich weiß, ist das Problem seit 2021 bekannt.

Ansonsten einen POC bereitstellen, denn alles andere ist nur eine Vermutung.

[sparrow]

@Dead_Eye: Du interpretierst da etwas in Sirius3 Worte, das er nicht gesagt hat. Er hat nicht gesagt, dass ein Request ausreicht. Er hat dich darauf hingewiesen, dass die Anzahl der Requests nicht der ausschlaggebende Punkt ist - denn das funktioniert ja noch immer.