W3 repository of Robert Schotthere you can find some un-/resolved errors which afflict my systemsStatus: searching errors should be main target of all computer users, so it will grow up fast :) |
PROBLEM: In 'google' werden keine Umlaute dargestaelt. Es erscheinen nur kryptische Symbole.
RESOLUTION: Hmm eigentlich habe ich das nicht ordentlich geloest. Aber eine ganz brauchbare Methode
dies zu beheben gibt es doch. Da ich immer mit 'CTRL-SPACE' meine Startseite (google) aufrufe,
habe ich den Link auf folgenden Eintrag geaendert:
'http://www.google.de/webhp?hl=de&;ie=iso-8859-15&;oe=iso-8859-15'
Wie ich gelesen habe ist diese Umlaute Problem immer mal wieder Mode. Und tritt auch nur bei bestimmten
Browsern (wie zum Beispiel 'opera') auf. Irgendwie sendet Google bei diesen Browsern die HTML Seite als
'UTF-8' Format und uebergeht die Einstellungen. Um auch auf den Suchschaltflaechen die richtigen Einstellungen
vorzunehmen muss die Datei '~/.opera/search.ini'
(bei Windows irgendwo anders) angepasst werden.
Aber zu diesem Thema solltet ihr ein wenig mit 'google' suchen.
PROBLEM: Beim Versuch ein Archive vom Tape zu holen kommen dei Meldungen:
tar: /dev/nst0: Cannot read: Cannot allocate memory tar: At beginning of tape, quitting now tar: Error is not recoverable: exiting now dd: reading `/dev/tape': Cannot allocate memory 0+0 records in 0+0 records outRESOLUTION: Das
'tar'
Kommando erlaubt die Angabe eines sogenannten --blocking-factors
welcher fuer
jedes Archiv neu gesetzt werden kann. Default ist das bei mir (debian) 20*512 Byte (10.240 Byte). Versucht man nun ein Archive vom
Tape zu holen welches nicht den Standartblockingfaktor besitzt kommen die oben angegebenen Meldungen. Bei
ist generell
der Blockfaktor mit anzugeben um die Daten vom Tape holen zu koennen. Sollte man den Faktor nicht wissen, kann man sich mit einem sehr
grossen Wert, langsam rantasten. Versucht:dd if=/dev/tape of=bla.dd ibs=1048576
'top'
PROBLEM: wenn 'top'
gestartet wird und das Fenster unter eine bestimmte Groesse gezogen wird, kommt es zum Crash.
Dies passiert mit der Version 3.1.8 genauso wie mit der letzten (24/02/2005) 3.2.5.
RESOLUTION: Loesung hab ich noch keine, also nur mal die Eckdaten notieren:
'procps-3.2.5.tar.gz'
besorgt und mit 'CFLAGS=-ggdb -O'
compiliert% 'gdb /usr/bin/top'
- hauen wirs erst mal in den debuger(gdb) run
- starten und sehen was passiertProgram received signal SIGSEGV, Segmentation fault. 0x400ded65 in mallopt () from /lib/libc.so.6
% ulimit -c unlimited - stellt in der aktuellen shell den CoreDumpMechnismus ein % top - ausfuehren und Fehler hervorrufen (shell auf 5 rows runterziehen) % erzeugt einen 'core' Datei im aktuellen Verzeichnis % Segmentation fault (core dumped) % % gdb /usr/bin/top ./core - alles an den debugger uebergeben % Core was generated by `top'. % Program terminated with signal 11, Segmentation fault. % .... blabla % #0 0x400e4d65 in mallopt () from /lib/libc.so.6 % (gdb) bt % #0 0x400e4d65 in mallopt () from /lib/libc.so.6 % #1 0x400e3ef3 in malloc () from /lib/libc.so.6 % #2 0x40024ac1 in xmalloc (size=1075458144) at proc/alloc.c:28 % #3 0x40028101 in openproc (flags=1075458144) at proc/readproc.c:796 % #4 0x0804b6a1 in procs_refresh (table=0x8066558, flags=73) at top.c:1089 % #5 0x0804e898 in summary_show () at top.c:2860 % #6 0x0804fc9a in frame_make () at top.c:3200 % #7 0x0804ff05 in main (dont_care_argc=1, argv=0x2) at top.c:3261 % (gdb)
strace -o trace.dump /usr/bin/top
- hier der Aufruf des tracers