W3 repository of Robert Schott

here you can find some un-/resolved errors which afflict my systems

Status: searching errors should be main target of all computer users, so it will grow up fast :)

baby errors:

TARGET: opera w3 browser (7.54 u1)
SEARCH: umlaute opera google

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.
TARGET: tar, dd, streamer, tape
SEARCH: dd +"Cannot allocate memory" tape
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 out
	
```
RESOLUTION: 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 (ibs = read 1048576 bytes at a time)

brain killer:

TARGET: 'top'
SEARCH: top SIGSEGV mallopt() buffer overflow

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:

neuste Quellen des '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 passiert

und den Fehler hervorrufen .. peng

Program received signal SIGSEGV, Segmentation fault.
0x400ded65 in mallopt () from /lib/libc.so.6

daraufhin nochmal gneauer drauf geschaut

% 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

[NODE: $Id: errors.shtml,v 1.3 2005/02/24 00:55:48 case Exp $ ] >
Author: pagemaster

home