Hallo Leute,
Programmiere C unter Linux/KDE (allerdings noch nicht lange).
Compiler: gcc
Debugger: kdbg
Der verwendete Sourcecode beendet, bei einer bestimmten Größe einer
Laufvariable, alle zur Laufzeit verwendeten Tasks(Debugger, compiler)und
sogar das BS selber Suse ist sozusagen abgemeldet und ich muss mich noch
mal anmelden.
Zunächst habe ich auf einen überlauf der Laufvariablen spekuliert
anschließend auf eine Überbelastung des RAMs. Hat sich beides als nicht
die Fehlerquelle rausgestellt. Den RAM konnte ich während der Laufzeit
mit Top(0,1s) beobachten die Laufvariable beträgt höchstens 330dezimal
und ist ein int außerdem würde es nicht zu einem so gravierenden Ausfall
führen.
Nun meine Frage gibt es einen Befehl unter linux der mir zeigen kann
warum die noch grade verwendeten tasks geschlossen wurden???
Danke für Hilfe
wiedo soll den das "Ding" undbedingt abschieren wenn ich Kdev. und KDE4
verwende wie bereits erwähnt am RAM liegt es nicht. Der Rechner sollte
eigentlich schnell genug sein um zwei größere Prozesse gleichzeitig zu
beweltigen. (2Kerne, Athlon X2 2,6Ghz und 4GB-RAM/DDR2)
Shell: wenn die shell abschmiert woran kann das den liegen?? Die shell
ist doch die Schnittstelle zwischen BS und Benutzer?? (oder irre ich
mich da??) beschäftige mich seit kurzem mit linux.
Es schmiert nicht deine Shell ab, sondern dein X-Server. "KDE4 +
plasmoids" bzw "KDE4 + kdevelop" "kann" zu reproduzierbarem Abschmieren
des X-Servers führt (ist als Bug bekannt). Grund ist offiziell ein
schludriger Grafikteiber von NVIDIA oder ATI oder INTEL. Lösung "Update
des Grafiktreibers" funktioniert manchmal.
Böse Zungen behaupten, dass KDE4 einfach noch ein paar Jahre braucht,
bis es verwendbar ist. Komischerweise ist das auch die offizielle
Meinung den KDE4 Teams, die aber nur im Forum vertreten, wenn was schief
geht (kannst ja mal bei forum.kde.org reinschaun) wird, aber auf der
Homepage totgeschwiegen wird.
> Shell: wenn die shell abschmiert woran kann das den liegen?? Die shell> ist doch die Schnittstelle zwischen BS und Benutzer??
Die Shell kann man unter anderem als eine der Schnittstellen zwischen BS
und Benutzer einsetzen, aber die scheint ja nicht das Problem zu sein.
Aus deinem Posting wird nicht so richtig klar, was du genau tust und was
daraufhin genau abschmiert:
> Der verwendete Sourcecode beendet, bei einer bestimmten Größe einer> Laufvariable, alle zur Laufzeit verwendeten Tasks(Debugger, compiler)
Der Sourcecode beendet den Compiler? Heißt das, der Fehler tritt beim
Compilieren auf? Oder meintest du, daß das erzeugte Programm beim
Ausführen den Effekt verursacht? Wieso läuft dann nebenher noch ein
Compiler?
> und sogar das BS selber Suse ist sozusagen abgemeldet und ich muss mich> noch mal anmelden.
Klingt schon nach X-Server. Was sollte das Programm denn eigentlich tun?
PS: Deine Fragezeichentaste prellt.
Danke für die vielen hinweise.
Was ich mache:
An meinem Rechner(PCI-X slot) ist hardware angeschlossen, deren daten
ausgelesen werden sollen. Genau genommen sind es 4096 ULONGLONG-Werte in
einem durchlauf d.h. wenn ich es mehrere durchläufe sind werden
dementsprechend viele Werte abgespeichert. Erreicht werden soll eine
kontinuirliche aufnahme von Werten. Sprich von der Peripherie die am
PCI-X hängt sollen daten ständig ausgelesen werden und auf der Platte
gespeichert werden. Mit durchläufen meine ich schleifendurchläufe bei
denen Daten aus einem Device gelesen werden.
Was läuft schief:
Beim Copilieren erzeuge ich eine Ausfürbaredatei, wenn ich diese starte
und ~330cycles speichere, passiert das besagte problem.
zuerst habe ich auf eine Überbeanspruchung des RAMs gedacht, hat sich
allerding als nicht der Grund herausgestellt.
Nun wollte ich wissen wie man an den Grund des "abschmierens" am besten
herausfinden kann.
p.s. Fragezeichentaste ist nun entprellt
1) Grafik-Schnickschnack ("Compositing", "Compiz", Halbtransparente und
wabbelnde Fenster...) ausschalten.
2) Vor dem Programm-Start mit ulimit den für dein Program verfügbaren
Speicher einschränken, auch den Stack.
3) Wenns immernoch passiert, Logfiles durchforsten: ~/.xsession-errors,
/var/log/messages, /var/log/Xorg.0.log.
> An meinem Rechner(PCI-X slot) ist hardware angeschlossen, deren daten> ausgelesen werden sollen.
Auf welchem Weg kommen denn diese Daten von der Hardware in dein
Programm?
erstmal danke für die Tipps.
Also die Grafik-Schnickschnacks sind aus und es klappt leider immer noch
nicht.
Mit ulimits rumgedoktorn habe ich leider noch nicht. Ich frage mich auch
wie ich mit ulimit ganz genau meinem Programm diesen Speicher zuweisen
kann.
Und wenn ich das richtig einstelle, frage ich mich was es bringen soll??
denn dann stürzt nur mein Prozess ab und nicht mehr der x-server.
Aber ich würde gerne wissen warum mein Programm den x-server zum
abstürzen bringt.
Das logfile überprüfe ich grade.
> Und wenn ich das richtig einstelle, frage ich mich was es bringen> soll?? denn dann stürzt nur mein Prozess ab und nicht mehr der> x-server.
Und das wäre nicht zumindest mal besser?
> Die Daten lese ich aus einem Device.>> Weg: Hardware(angeschlossen) ->|PCI-x|-> DMA -> ..-> Festplatte
Mir ging es eher darum, wie du auf das Device zugreifst. Hast du da
einen Treiber, der vielleicht fehlerhaft ist? Oder machst du das mit
irgendwelchen ioperm-Fiesheiten? Vielleicht ist das Problem ja an der
Stelle zu suchen.
Rolf Magnus schrieb:
> Mir ging es eher darum, wie du auf das Device zugreifst. Hast du da> einen Treiber, der vielleicht fehlerhaft ist? Oder machst du das mit> irgendwelchen ioperm-Fiesheiten? Vielleicht ist das Problem ja an der> Stelle zu suchen.
axo. an dieser Stelle muß ich zugeben das mir dieser code mit der
Hardware zugeschmissen wurde und ich muß durchwursteln.
wie das Aussieht aus einem treiber gelesen:
" /* Allocate memory for the receiving buffer */
hDevice = open("/dev/ics554-1", O_RDWR);" // ics..(hardware)
Hier ein Ausschnitt aus dem logfile(message): mir fehld leider die
erfahrung daraus was zu interpritieren. Ich habe mein programm um
13:46:~50 gestartet.
bin für jeden tip dankbar
Jan 20 13:46:58 pc74-s74 kernel: ics554demo_ohne invoked oom-killer:
gfp_mask=0x40d1, order=2, oomkilladj=0
Jan 20 13:46:58 pc74-s74 kernel: Pid: 4159, comm: ics554demo_ohne
Tainted: P W 2.6.27.7-9-pae #1
Jan 20 13:46:58 pc74-s74 kernel: [<c0106570>] dump_trace+0x6b/0x249
Jan 20 13:46:58 pc74-s74 kernel: [<c01070a5>] show_trace+0x20/0x39
Jan 20 13:46:58 pc74-s74 kernel: [<c035175f>] dump_stack+0x71/0x76
Jan 20 13:46:58 pc74-s74 kernel: [<c01702f0>]
oom_kill_process+0x67/0x20f
Jan 20 13:46:58 pc74-s74 kernel: [<c01708bc>] out_of_memory+0x196/0x1c0
Jan 20 13:46:58 pc74-s74 kernel: [<c0173bf6>]
__alloc_pages_internal+0x2e2/0x3e6
Jan 20 13:46:58 pc74-s74 kernel: [<c0190cff>]
alloc_pages_current+0x95/0x9b
Jan 20 13:46:58 pc74-s74 kernel: [<c0173078>] __get_free_pages+0xa/0x16
Speicher Voll=> Kernel tötet willkürlich Prozesse um wieder Ram
freizukriegen.
Also:
Mehr swapspace anlegen
oder
Programm reparieren, dass es weniger Speicher braucht.
oder
mit ulimit den Speicher limitieren (oben bereits geschrieben), dann ist
NUR dein Program betroffen, der Rest (X+KDE) läuft weiter.
Repariern musst du deinen Code dann aber trotzdem.
Gerry E. schrieb:
> Vielleicht ist ja auch einfach nur ein Puffer zu klein.
Dann würde ja nur sein Programm rausfliegen (SIGSEGV).
Bei ihm läuft aber der OOM_KILLER (siehe Logfile-Ausschnitt) und dieser
tötet halt ein Programm, dass für seine X bzw KDE-Session essentiell ist
=> er wird "ausgeloggt", genau wie er es weiter oben beschrieben hat.
d.H. er muss entweder mehr Speicher zur Verfügung stellen oder weniger
davon verbrauchen.
danke für die vielen Vorschläge.
Wie es sich anhöhrt komme ich nicht drumm herum den code zu reparieren
;-).
Denn wie ich es vermute wird das Problemchen nicht aufhöhren auch wenn
ich im doppelt soviel speicher zur verfügung stelle denn dieses Programm
muß konstannt laufen können und mehr RAM würde glaube ich das
Problemchen nur einwenig zeitlich verlagern.
Wie das aussieht wird im programm gemapt: und das könnte einwenig zuviel
sein oder??????
//aus hauptprogramm///////////////////////////////////////
for(i = 0; i < eingabe.cycle; i++) {
.
.
rbuffer12[i] = (ULONGLONG *) ics554AllocateDmaBuffer
(hDevice,BytesToRead);
.
.
}
///die Funktion:ics554AllocateDmaBuffer(..)////////////////////////
void *
ics554AllocateDmaBuffer (HANDLE hnd, int size)
{
int rc;
ICS554_MEMRQ memrq = {0,NULL,NULL};
if (size) {
#ifndef WIN32
memrq.npages = (size + PAGE_SIZE - 1) / PAGE_SIZE;
rc = ioctl (hnd, ICS554_RESERVE_PAGES, &memrq);
if (rc != -1) {
memrq.address =
(int *) mmap ((void *) 0, memrq.npages * PAGE_SIZE,
PROT_READ | PROT_WRITE, MAP_FILE | MAP_SHARED, hnd,
0);
if (memrq.address == (int *) -1)
{
ioctl (hnd, ICS554_RELEASE_PAGES, &memrq);//
memrq.address = NULL;
}
}
Hallo, hab noch eine frage, gibt es eigentlich eine andere Variante
ausser mmap(Memory Mapping) Daten kontinuirlich vom ram aus auszulesen
und auf die Festplatte zu bringen? würde dies am besten so
zeitunkritisch wie möglich machen? welche Methode ist die am besten
geeigente um Daten vom RAM auf die festplatte zu bringen??
threads? pipes etc. ??
