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
also wenn Du sozusagen abgemeldet wurdest, dann ist wohl eher die Shell abgeschmiert.
Du verwendest Kdevelop und KDE4. Und da wunderst du dich, dass das Ding abschmiert?
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.
Die Daten lese ich aus einem Device. Weg: Hardware(angeschlossen) ->|PCI-x|-> DMA -> ..-> Festplatte
> 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.
Alibaba schrieb:
> Programmiere C unter Linux/KDE (allerdings noch nicht lange).
Deinen eigenen Code hälst Du für fehlerfrei?
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. ??
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.