expertenaustausch > comp.os.* > comp.os.unix.shell

Helmut Schellong (11.12.2018, 19:13)
Ich habe heute (erneut) eine Schilderung über Probleme mit
bish unter Windows erhalten.
(Per Telefon, wohl aus dem Ländle.)
Und zwar diesmal nicht geringfügig.

Es soll andauernd (!) SIGSEGV geben, u.a. wenn ein Kommando
eingetippt wird, das nicht existiert.
$PWD soll nicht funktionieren, in der Prompt-Programmierung,
und einiges andere ebenso nicht.
Mit Version 4.12 (2007) soll fast alles funktionieren.
Mit Version 6.85 soll vieles nicht mehr funktionieren.
Es soll helfen, wenn in einer autoexec.hsb steht: echo %c
und diese ausgeführt wird (?!).
Es soll auch auf anderen Rechnern ebenso wenig funktionieren.



PE32+ executable (console) x86-64 (stripped to external PDB),
for MS Windows

Tatsache ist, daß bsh/bish seit Jahrzehnten bei mir unter WinNT,
Win2000, Vista und nun unter Windows10 makellos funktioniert.
Die beiden Bilder oben dokumentieren und *beweisen* dies!

Ich weiß nicht, was bei den Leuten, die von Problemen berichten,
los ist.
Ich bekomme solche Verhaltensweisen bei mir nicht hergestellt!
Auch nicht, wenn ich mich bemühe!

Sind deren Systeme komplett 'im Arsch', total verkonfiguriert?
Oder können die x86-64 nicht?
Das kann aber nicht sein, denn ein falsches Exe-Format wird
doch sofort zurückgewiesen.

Hat jemand von hier solche oder ähnlich abenteuerliche Probleme?

Einer berichtete hier(?), bish würde bei ihm unter Slackware mit
SIGSEGV sofort abschmieren - mit Schuldzuweisung an mich!
Komischerweise war das nur bei ihm so.
Unter einem anderen Linux kompiliert, funktionierte dann
bish auch bei ihm.
Woran lag es?: Weder an mir, noch an ihm.
Joerg.Schilling (12.12.2018, 13:22)
In article <puor83$bq0$1>,
Helmut Schellong <rip> wrote:
>Ich habe heute (erneut) eine Schilderung über Probleme mit
>bish unter Windows erhalten.
>(Per Telefon, wohl aus dem Ländle.)
>Und zwar diesmal nicht geringfügig.
>Es soll andauernd (!) SIGSEGV geben, u.a. wenn ein Kommando
>eingetippt wird, das nicht existiert.
>$PWD soll nicht funktionieren, in der Prompt-Programmierung,
>und einiges andere ebenso nicht.
>Mit Version 4.12 (2007) soll fast alles funktionieren.
>Mit Version 6.85 soll vieles nicht mehr funktionieren.


>Einer berichtete hier(?), bish würde bei ihm unter Slackware mit
>SIGSEGV sofort abschmieren - mit Schuldzuweisung an mich!


Ja, das ist auch gerechtfertigt, denn solche Fehler treten dann auf, wenn man
zu wenig testet und Speichernutzungsfehler einbaut.

Nicht ohne Grund wird sehr viel Zeit in das regelmäßige umfangreiche Testen des
aktuellen Bourne Shells gestecktund der kann sich in den meisten Fällen davon
automatisch durch einen Longjmp vor den nächsten Prompt von solchen Problemen
erholen.

Bei Programmen, die viel mit malloc() arbeiten, wie es bei Shells üblich ist,
ist es nicht selten, daß ein Problem z.B. auf einem Rechner mit einem um einen
Buchstaben längeren oder kürzeren Hostnamen aus unkerklärlichen Gründen nicht
auftritt. Aber wenn es auftritt, ist sowas ja leicht zu debuggen.

Wenn das auf Linux passiert ist, sind zwar die Debug-Möglichkeiten nicht
optiomal, aber immer noch besser als auf Win-DOS und mit einem Stacktrace
solltest Du den Fehler dann ja innerhalb von 10 Minuten gefunden und beseitigt
haben, oder?

und in Zukunft den Code besser testen ;-)
Helmut Schellong (12.12.2018, 20:01)
On 12/12/2018 12:22, Joerg.Schilling wrote:
[..]
> solltest Du den Fehler dann ja innerhalb von 10 Minuten gefunden und beseitigt
> haben, oder?
> und in Zukunft den Code besser testen ;-)


Ich wundere mich oft über (manchmal) nicht vorhandene Logik
diverser Zeitgenossen:

Wenn eine Exe unter mehreren Linux-Systemen makellos funktioniert,
auch unter FreeBSD, das ja Linux-Exe unterstützt,
jedoch unter einem bestimmten Linux sofort mit SIGSEGV abschmiert,
dann ist unter logischen Gesichtspunkten am wahrscheinlichsten
dasjenige System schuld, unter dem diese Exe einzig abstürzt.

Es kann letztlich, mit geringer Wahrscheinlichkeit, das
Entwicklungssystem schuld sein, wo die Exe kompiliert wurde.

Der Quellcode kann nicht schuld sein, da dieser für alle
Betriebssysteme gleich ist - jedenfalls bis zum ersten Prompt.
Der kompilierte Quellcode läuft also problemlos jeweils unter
mehreren Systemen: Windows, Linux, Unix.
Unter einem jedoch nicht - Schuld hat also dieses eine System.

Der DynMem-Modul kann erst recht nicht schuld sein, denn er verwendet
identischen Code überall und benutzt die C-Standard-Funktion malloc()
nur einmal in der Funktion main(), um für die relevanten Bereiche
jeweils mehr als 40000 Byte Speicher zu allokieren.

Einen Speichernutzungsfehler kann es nicht geben.
Weil bis zum ersten Prompt nur wenige hundert Byte gebraucht werden
und weil _vor_ Erreichen von Pufferenden der Speicher verdoppelt wird.






Wenn also, wie die Bilder es zeigen, bish unter Windows makellos
funktioniert, jedoch bei irgendeinem Nutzer dauernd mit SIGSEGV
abschmiert oder in anderer Weise nicht funktioniert, bei denjenigen
Aktionen, die in den Bildern zu sehen sind, dann tut es mir leid,
ich kann dann diesem Nutzer nur allgemein helfen, jedoch den
bish-Code zu prüfen, wäre Unsinn.
Eike Rathke (13.12.2018, 02:08)
Das ist so drollig, ich kann nicht anders..

* Helmut Schellong, 2018-12-12 18:01 UTC:
> On 12/12/2018 12:22, Joerg.Schilling wrote:


Tja, dann musst du wohl mal nachsehen,
a) ob sich ein auf dem Zielsystem kompiliertes 6.85 binary genauso
kaputt verhaelt
b) wie du das debugst
c) was du in den 11 Jahren geaendert hast
d) wie du per binary search in den commits versuchen kannst den
fehlerhaften commit einzugrenzen
e) was sich vielleicht in benutzten APIs/ABIs in 11 Jahren geaendert hat

>>> Einer berichtete hier(?), bish würde bei ihm unter Slackware mit
>>> SIGSEGV sofort abschmieren - mit Schuldzuweisung an mich!

>> Ja, das ist auch gerechtfertigt, denn solche Fehler treten dann auf, wenn man
>> zu wenig testet und Speichernutzungsfehler einbaut.


> Ich wundere mich oft über (manchmal) nicht vorhandene Logik
> diverser Zeitgenossen:


> Wenn eine Exe unter mehreren Linux-Systemen makellos funktioniert,
> auch unter FreeBSD, das ja Linux-Exe unterstützt,
> jedoch unter einem bestimmten Linux sofort mit SIGSEGV abschmiert,
> dann ist unter logischen Gesichtspunkten am wahrscheinlichsten
> dasjenige System schuld, unter dem diese Exe einzig abstürzt.


Unter logischen Gesichtspunkten ist der Code schuld, der zwar auf vielen
Systemen funktioniert aber auf einigen halt nicht. Das System schiesst
dein Programm ja nicht aus Spass ab, sondern weil es sich fehlverhaelt.

> Der Quellcode kann nicht schuld sein, da dieser für alle
> Betriebssysteme gleich ist - jedenfalls bis zum ersten Prompt.
> Der kompilierte Quellcode läuft also problemlos jeweils unter
> mehreren Systemen: Windows, Linux, Unix.
> Unter einem jedoch nicht - Schuld hat also dieses eine System.


Echt drollig.. sicherlich funktioniert jeder Code auf jedem System
gleich, egal welche Plattform, welcher Prozessor, egal ob Little Endian
oder Big Endian, ob das Bus-System Wortzugriffe auf ungeraden Adressen
erlaubt oder nicht, ob unitialisierter Speicher mit 0 oder was anderem
oder gar nicht (also zufaellig) initialisiert ist, was bei out-of-bounds
Zugriffen im Speicher steht oder ob das System diese gleich mit einem
SIGSEGV quittiert. Da stehst du mit deinem Code natuerlich total
drueber, an dem kann es ja gar nicht liegen.

Traeum weiter.

Eike
Juergen Ilse (13.12.2018, 11:05)
Hallo,

Helmut Schellong <rip> wrote:
> Ich wundere mich oft über (manchmal) nicht vorhandene Logik
> diverser Zeitgenossen:


Bei dir wundert mich eigentlich schon lange kaum noch etwas ...

> Wenn eine Exe unter mehreren Linux-Systemen makellos funktioniert,
> auch unter FreeBSD, das ja Linux-Exe unterstützt,
> jedoch unter einem bestimmten Linux sofort mit SIGSEGV abschmiert,
> dann ist unter logischen Gesichtspunkten am wahrscheinlichsten
> dasjenige System schuld, unter dem diese Exe einzig abstürzt.


Falsch. Dann ist es am wahrscheinlichsten, dass dieses eine System eine
Umgebung bereit stellt, in der das Programm (ich weigere mich, hier den
von dir verwendeten "DOS inspirierten" Ausdruck zu verwenden) nicht
funktioniert. Wenn das Programm entworfen wurde, um in allen Linux-
umgebungen zu laufen, und eine gefunden wird, in der es nicht laeuft,
wuerde ich den Fehler doch zuerst in diesem Programm suchen (zuerst,
indem ich versuche herauszufinden, welche Besonderheit denn bei der
einen Umgebung vorliegt, die fuer den Programmabsturz verantwortlich
sein koennte).

> Es kann letztlich, mit geringer Wahrscheinlichkeit, das
> Entwicklungssystem schuld sein, wo die Exe kompiliert wurde.


Es kann auch schlicht und ergreifend ein Bug im Code des Programms sein,
der sich nur unter ganz bestimmten Umstaenden (vielleicht sehr grosses
Environment, bestimmte "unerwartete Werte fuer Environment Variablen",
vielleicht aber auch bestimmte im Hintergrund laufende Programme, die
Resourcen belegen, die das abstuerzende Programm fuer sich allein zu
beanspruchen versucht, ...).

> Der Quellcode kann nicht schuld sein, da dieser für alle
> Betriebssysteme gleich ist -


.... aber die Systemumgebung in der das Programm ausgefuehrt wird, ist
moeglicherweise nicht ueberall gleich, und wenn deine shell dafuer ge-
schrieben ist, auf allen Linux-Systemen zu laufen und diese Anforderung
nicht erfuellt, dann ist vielleicht doch der Quelltext deiner shell
schuld.

> jedenfalls bis zum ersten Prompt.


Das ist eine gewagte und unbewiesene These.

> Der kompilierte Quellcode läuft also problemlos jeweils unter
> mehreren Systemen: Windows, Linux, Unix.
> Unter einem jedoch nicht - Schuld hat also dieses eine System.


Das ist eine sehr voreilige Schlussfolgerung.

Tschuess,
Juergen Ilse (juergen)
Joerg.Schilling (13.12.2018, 12:53)
In article <purien$732$1>,
Helmut Schellong <rip> wrote:
>On 12/12/2018 12:22, Joerg.Schilling wrote:


>Ich wundere mich oft über (manchmal) nicht vorhandene Logik
>diverser Zeitgenossen:
>Wenn eine Exe unter mehreren Linux-Systemen makellos funktioniert,
>auch unter FreeBSD, das ja Linux-Exe unterstützt,
>jedoch unter einem bestimmten Linux sofort mit SIGSEGV abschmiert,
>dann ist unter logischen Gesichtspunkten am wahrscheinlichsten
>dasjenige System schuld, unter dem diese Exe einzig abstürzt.


Also diese Terrarienbewohner gibt es auf UNIX artigen BS nicht....

Mit Deiner Argumentation belegst Du allerdings, daß Du anscheinend
noch ein Programmieranfänger bist.

Fakt ist, daß ich mit Hilfe von Heiko Eißfeld und modernen Testmethoden
vor ca 1,5 Jahren im Bourne Shell Bugs gefunden habe, die dort seit 1982, also
seit dem Umbau der Speicherverwaltung zur Umgehung der CPU Design Bugs des
Motorola 68000 dort eingebaut waren. Jetzt wirst Du Dich natürlich fragen,
warum solche Bugs 35 Jahre lang nicht bemerkt wurden.... Nun, das liegt daran,
daß ein Bug in einem Programm halt keine _Garantie_ zum Absturz bedeutet,
sondern lediglich eine Möglichkeit zum Absturz bietet.

So eine Möglichkeit kann durch "geeignete" Randbedingungen in der Tat über sehr
lange Zeit nicht genutzt werden. Ist deshalb jetzt das Betriebssysstem schuld,
auf dem es dann letztlich doch passiert? Nein, natürlich nicht.

>Der Quellcode kann nicht schuld sein, da dieser für alle
>Betriebssysteme gleich ist - jedenfalls bis zum ersten Prompt.
>Der kompilierte Quellcode läuft also problemlos jeweils unter
>mehreren Systemen: Windows, Linux, Unix.
>Unter einem jedoch nicht - Schuld hat also dieses eine System.


Nein, selbstverständlich ist das falsch.

Die Wahrscheinlichkeit, daß die Speicherverwaltung des Systems schuld ist, ist
extrem gering, denn die Art der Nutzung und die Tatsache, daß sehr viele
unterschiedliche Programme den Code verwenden sorgt dafür eventuelle Bugs
schnell zu finden.

>Der DynMem-Modul kann erst recht nicht schuld sein, denn er verwendet
>identischen Code überall und benutzt die C-Standard-Funktion malloc()
>nur einmal in der Funktion main(), um für die relevanten Bereiche
>jeweils mehr als 40000 Byte Speicher zu allokieren.


Wie bereits oben erklärt, Du scheint noch nicht viel Programmiererfahrung zu
haben.

Die klassische UNIX malloc() Implementierung erlaubt vieles, das nach Standard
unzulässig ist. Darunter z.B.:

- Nutzung eines gerade freigegebenen Speichers, solange keine andere
Operation aus dem Bereich malloc()/free()/.... verwendet wurde.

- Mehrfaches Aufrufen von free() auf den gleichen Speicher.

- ...

Die aktuelle Linux Implementierung erlaubt zumindest die beiden oben explizit
erwähnten Nutzungen nicht.

Aber wenn Du ein SIGSEGV hast, hast Du auch einen Codedump wenn Du es willst
und damit einen Stacktrace, der Dich, falls Du Debuggen kannst, schnell zum
Fehler führen wird.

Ich habe für solche Zwecke übrigens seit über 30 Jahren eine eigene malloc()
Implementierung, die sich merkt, welches Stück Speicher von welcher Zeile im
Code alloziert wurde und die es sofort meldet, wenn etwas verbotenes gemacht
wurde. Dazu gibt es zusätzlich auch noch vor und nach dem vergebenen
Speicherstücken einen Streifen "geharkten Sand", auf dem man sofort bemerkt,
wenn dort jemand draufgetreten ist.

Damit bekomme ich also dann nach kurzer Zeit eine Meldung die sagt, der auf
Zeile xxx in Datei yyy allozierte Speicher ist gerade kaputtgegangen.
Joerg.Schilling (13.12.2018, 12:59)
In article <N3e8I5c11a292T5dfc>,
Eike Rathke <erack-nutznetz.n> wrote:

>d) wie du per binary search in den commits versuchen kannst den
> fehlerhaften commit einzugrenzen


Wir haben keinen Quellcode, wir können auch nicht mal ahnen, ob er ein
Versionsverwaltungssystem verwendet. Ohne hat er vielleicht nur gelegentlich
eine alte Version aufgehoben und dann so viele Änderungen dazwischen, daß
diese Methode nicht mehr funktioniert.

Ich verwende das Suchen in den Versionen auch nur im Notfall, weil das viel
Zeit kostet und man meist durch einfaches Debuggen und Nachdenken schneller zum
Ziel kommt.
Eike Rathke (13.12.2018, 20:18)
* Joerg.Schilling, 2018-12-13 10:59 UTC:
> In article <N3e8I5c11a292T5dfc>,
> Eike Rathke <erack-nutznetz.n> wrote:


>>d) wie du per binary search in den commits versuchen kannst den
>> fehlerhaften commit einzugrenzen


> Wir haben keinen Quellcode, wir können auch nicht mal ahnen, ob er ein
> Versionsverwaltungssystem verwendet.


Das ist wohl wahr, ist mir aber letztendlich egal wie sein batsch
verwaltet ist. Stand ja auch erst an vierter Stelle der moeglichen
Vorgehensweisen ;-)

> Ich verwende das Suchen in den Versionen auch nur im Notfall, weil das viel
> Zeit kostet und man meist durch einfaches Debuggen und Nachdenken schneller zum
> Ziel kommt.


Meistens. Es kann jedoch ein prima Helfer sein, insbesondere wenn QA und
Entwickler nicht in Personalunion sind.

Sidetrack: auch per source commit gebaute binaries lassen sich mit
entsprechender Referenz-commit-message in git committen und
dann einfach mit git-bisect ausfuehren, man spart sich dann
das ganze Neugebaue.

Eike
Thomas Koenig (13.12.2018, 21:07)
Joerg.Schilling
<Joerg.Schilling> schrieb:

> Ich habe für solche Zwecke übrigens seit über 30 Jahren eine eigene malloc()
> Implementierung, die sich merkt, welches Stück Speicher von welcher Zeile im
> Code alloziert wurde und die es sofort meldet, wenn etwas verbotenes gemacht
> wurde. Dazu gibt es zusätzlich auch noch vor und nach dem vergebenen
> Speicherstücken einen Streifen "geharkten Sand", auf dem man sofort bemerkt,
> wenn dort jemand draufgetreten ist.


Man kann für sowas mittlerweile auch valgrind sowie -fsanitize=address,
-fsanitize=undefined und ähnliches verwenden.

Allerdings muss man für beides ziemlcih viel Geduld mitbringen, weil
einem da auch in Code, den man eigentlich für fehlerfrei hielt, noch
jede Menge Fehler begegnen.

Und valgrind ist sehr langsam, aber dafür auch verflixt gründlich.
Helmut Schellong (13.12.2018, 21:47)
On 12/13/2018 01:08, Eike Rathke wrote:
> Das ist so drollig, ich kann nicht anders..
> * Helmut Schellong, 2018-12-12 18:01 UTC:
> Tja, dann musst du wohl mal nachsehen,
> a) ob sich ein auf dem Zielsystem kompiliertes 6.85 binary genauso
> kaputt verhaelt
> b) wie du das debugst
> c) was du in den 11 Jahren geaendert hast
> d) wie du per binary search in den commits versuchen kannst den
> fehlerhaften commit einzugrenzen
> e) was sich vielleicht in benutzten APIs/ABIs in 11 Jahren geaendert hat


Ich kann keine Kompilierung auf dem Zielsystem vornehmen, weil
ich nun Win10 habe und Win7 nie hatte, sondern XP und Vista.
Ich habe keine Debug-Möglichkeit unter Windows, sondern nur
einen CONSOLE-C-Compiler x86_64 - sonst nichts.
Ich relevanten Code wurde nichts geändert, seit vielleicht 20 Jahren.
Aber es wurde auf 64bit umgestellt, und es wurde damit
auf einen neuen Compiler umgestellt.

Ich habe nach tagelanger Suche ein Skript gefunden, das unter
_Windows_ SIGSEGV produziert:


Ausgabe:
---------------------------------------------------------------
Daten laden : l [#]
Kandidaten-Namen: n name1 name2 ...
Leistungswerte : w 88888 44.44 ... {>|<}{gew}{bez}
Berechnung : b
Beenden : E
: l
max=3
N=6 W=2
*** SIGSEGV ***
xz-0 bzip2 gzip xz xz-T0 xz-0-T0
< 60.0 size 49941772.0 57273254.0 61148843.0 40579988.0 ...
< 40.0 time 12.46 19.71 9.47 103.33 61.04 6.73
---------------------------------------------------------------
Bis zum Signal hat das Skript bereits viel getan.
Beispielsweise sich selbst bis zum Dateiende gelesen
und die Daten max=3 N=6 W=2 erarbeitet.

Code-Position:
---------------------------------------------------------------
Zeigen() {
[ N -gt 0 ] || return 0
local o:09 n:03 w:03 tmp:.30 *** SIGSEGV ***
---------------------------------------------------------------

Funktionieren:
--------------
Zeigen() {
echo zeigen $((N-1))
[ N -gt 0 ] || return 0
local o:09 n:03 w:03 tmp:.30

Zeigen() {
[ N -gt 0 ] || return 0
local k=000000000 x=000 y=000 gmp=.......................
local o:09 n:03 w:03 tmp:.30

Funktioniert nicht:
-------------------
Zeigen() {
echo zeigen xxxxxxxx
[ N -gt 0 ] || return 0
local o:09 n:03 w:03 tmp:.30

Es ist sichtbar, daß da kein Fehler ist, der sich
einkreisen läßt. Es wirkt wie randomized.
Durch bestimmte Dummy-Code-Hinzufügungen wird der SIGSEGV
verhindert.
Dadurch wird das gesamte Skript komplett abgearbeitet!

Und jetzt kommt's:

Wenn ich statt mit -O1 mit -O0 kompiliere, ist diese
bish-Exe total kaputt! Sie macht bei jedem beliebigen
Datei-Argument sofort SIGSEGV und zeigt echo A am
Dateianfang nicht!
Wenn ich statt mit -O1 mit -O2 kompiliere, gibt es
keinen SIGSEGV mehr -> Fehler ist scheinbar repariert!

Dieses Kompilieren mit verschiedener Optimierung
darf aber nicht SIGSEGV unterdrücken oder hervorbringen!
Das Verhalten der Exe muß exakt gleich bleiben, bis auf
Geschwindigkeitsunterschiede.

/......./de/bin/bish_lx.bin sieger.bish

Wenn ich das mache, also meine Linux-Exe unter FreeBSD,
funktioniert immer alles, ohne das kleinste Zucken.
Das Verhalten mit der FreeBSD-Exe ist ebenso einwandfrei.
Und zwar seit Jahren, bei hunderten von Benutzungen.

Das ist eine kleine Schilderung meiner aktuellen Erkenntnisse.

Bei dem Nutzer, der mich anrief, ist die Fehlererscheinung
genau so seltsam:
Er ruft jeweils zuvor ein Skript 'hsb' auf, in dem nur
'echo \c' steht. Das verhindert meistens einen SIGSEGV
bei dem nachfolgenden, richtigen Arbeitsskript!
Total bescheuert!
Helmut Schellong (13.12.2018, 21:52)
On 12/13/2018 20:07, Thomas Koenig wrote:
> Joerg.Schilling
> <Joerg.Schilling> schrieb:


> Man kann für sowas mittlerweile auch valgrind sowie -fsanitize=address,
> -fsanitize=undefined und ähnliches verwenden.


Hast Du (mir) schon mal empfohlen.
Hatte ich auch angewandt.
Mit dem Ergebnis, daß a.out beim Aufruf sofort mit
SIGSEGV abbrach.
Karl Davis (13.12.2018, 23:02)
Helmut Schellong <rip> wrote:
> Der Quellcode kann nicht schuld sein,


Du bist echt ein Held. Nicht. Aber lustig.

Karl
Karl Davis (13.12.2018, 23:08)
Joerg.Schilling wrote:
[...]

Jörg, Dein posting finde ich konstruktiv, verständlich und hilfreich!
Sowas muss auch mal gesagt werden...

Karl
Karl Davis (13.12.2018, 23:09)
Helmut Schellong <rip> wrote:
> Mit dem Ergebnis, daß a.out beim Aufruf sofort mit
> SIGSEGV abbrach.


Ups. Und dennoch sind immer die anderen schuld? Was stimmt mit Deiner
Wahrnehmung nur nicht!?

Karl
Helmut Schellong (14.12.2018, 02:18)
On 12/13/2018 22:09, Karl Davis wrote:
> Helmut Schellong <rip> wrote:
>> Mit dem Ergebnis, daß a.out beim Aufruf sofort mit
>> SIGSEGV abbrach.

> Ups. Und dennoch sind immer die anderen schuld? Was stimmt mit Deiner
> Wahrnehmung nur nicht!?


Du willst hier nur dumm rumhauen, nicht aber lesen und verstehen,
worum es überhaupt geht.
Hier habe ich niemandem Schuld zugewiesen.
Es sind aus meiner Sicht auch nicht immer nur die anderen Schuld.
Das habe ich hier auch nicht geschrieben oder behauptet.
Aber Du behauptest, ich hätte, weil Du nicht richtig lesen
kannst und das auch nicht willst.

Ähnliche Themen