Gast
#1344035
Hallo, weis zufällig jemand wie ich bei Ubuntu die Serielle schnittstelle wieder schliessen kann?? Habe ein Programm dass manchmal abschmiert und die schnittstelle ist dann noch offen.. Danke schon mal..
Fange das Signal SIGSEGV ab, welches an das Programm gesendet wird, wenn es durch ungültige Pointer abstürzt, und schließe das Datei-Handle:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
Siehe
1 | |
PS: Die Schnittstelle ist nach einem Absturz nur kurze Zeit noch offen, danach schließt der Kernel sie automatisch.
Gast
#1344181
hmm irgdnwie schiesst es mir den Port immer ab, wenn ich dann vom System darauf zugreifen will bekomme ich einen "Input/Output Error" und von alleine schliesst er sich auch nicht.. ??
Gast
#1344292
irgendwas stimmt da nicht. der port wird nicht mal geschlossen wenn ich alle prozesse kille ( strg + alt + <---- )
phreak schrieb: > irgendwas stimmt da nicht. der port wird nicht mal geschlossen wenn ich > alle prozesse kille ( strg + alt + <---- ) Ähm, das killt nur den X-Server. Grafische Programme können darauf reagieren und sich beenden, müssen sie aber nicht und können fröhlich weiter laufen. Versuch mal "lsof | grep /dev/ttyXX" um herauszufinden welche Prozesse noch auf die Schnittstelle zugreifen. Hast du mal meinen Code oben eingebaut, und die Schnittstelle wird trotzdem nicht geschlossen oder was?
Gast
#1344374
habe es eingebaut, aber das programm hat wohl noch andere Porbleme.. :(
1 | |
1 | |
2 | |
versuche es jetz mal mit der libserial btw: Danke für die Unterstützung :)
Gast
#1344436
Was machsten da fürn Kram? :-) Beim Beenden sollte eigentlich automatisch aufgeräumt werden. Oder was meinst du mit 'schließen'?
Gast
#1344900
hehe ja sollte, aber das klappt noch nicht... folgendes. Vielleicht hilft das hier ja noch weiter:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
wenn ich jetzt den Port öffne scheint er irgdnwie offen zu sein, zumindest ist er danach blockiert :/ wenn ich ihn wieder schliesse rs232.close() ist er trotzdem noch blockiert... und beim Lesen kommt immer nur 0 raus ... damit ich nicht nach jedem build neustarten muss wollt ich fragen wie ich den Port abwürgen kann, oder alternativ warum das Programm so ein Blödsinn macht ;)
Gast
#1345854
Einfach aus- und wieder einstecken? Ist doch nach dem Namen zu urteilen, ein USB-seriell-Wandler.
Gast
#1346496
aus und einstecken hilft auch nicht :(
Gast
#1370015
Hallo, ich hab exakt dasselbe Problem. Ich verwende ebenfalls die libserial und muss jedes mal, wenn die Verbindung mit meinem ftdi-device (serial2USB-Converter /dev/ttyUSB0) unsanft beendet wird, den PC neu starten. Der Kernel erkennt zwar, wann das device eingesteckt/abgezogen wird (dmesg), allerdings meldet er scheinbar nicht den socket ab.
1 | |
spuckt folgendes aus...
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
...und dmesg nach Abziehen/anstecken folgendes...
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
Also falls es einen Befehl gibt, wie man das Problem beheben kann, ohne jedes mal den Rechner neu zu starten, bitte bitte posten.
Gast
#1371597
Ich kann eigentlich jedem nur raten, bei Funktionsaufrufen auch die Rückgabewerte zu überprüfen, auszuwerten und angemessen darauf zu reagieren. Dafür sind die da! Wenn ich diese Codesequenz lese:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
dann ist da ein gutes Stück Hoffnung drin, das aber laut Murphy, na Ihr wisst schon...
Ich hatte den Effekt auch schon, dass bei einem Fehler in einem USB/seriell-Wandler dieser und alle anderen(!) nicht mehr ansprechbar waren. Statt Reboot tut's dann auch ein modprobe -r usbserial (natürlich nachdem alle USB/seriell-Prozesse beendet wurden). Mit neueren Kernels (ab ca. 2.6.29) scheint das Problem weg zu sein; es trat jedenfalls nicht mehr auf. ---- (Übrigens, weiter oben: Ein SIGSEGV kann vom verursachenden Prozess nicht abgefangen werden - der Prozess bekommt vom Kernel keine Chance dazu mehr, denn er wird sofort beendet und hört mit dem SEGV auf zu laufen. Es wird kein Signalhandler im Prozess aufgerufen. Sein I/O wird geschlossen (auch vom Kernel).)
Gast
#1373497
Der mizch mag ja Recht haben, aber wer Returncodes von Libc-Aufrufen, auch wenn sie in C++ verpackt sind, ignoriert, der soll hiermit gewarnt werden: Irgendwann geht das in die Hose! Unter Linux ist es ja doch so, dass wenn ein Prozess endet, alle von ihm belegten Dateien (dazu zählen auch die seriellen Schnittstellen) freigegeben werden. Aber darum geht es doch hier nicht! Das laufende Programm soll bemerken, dass ihm die Schnittstelle abhanden gekommen ist. Wie soll das denn gehen, wenn sich keiner darum kümmert?
Hazeh Zimmerer schrieb: > (Übrigens, weiter oben: Ein SIGSEGV kann vom verursachenden Prozess > nicht abgefangen werden - der Prozess bekommt vom Kernel keine Chance > dazu mehr, denn er wird sofort beendet und hört mit dem SEGV auf zu > laufen. Es wird kein Signalhandler im Prozess aufgerufen. Sein I/O > wird geschlossen (auch vom Kernel).) Ganz sicher? Bei mir funktioniert's:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
Müsste der Gnome Bug Buddy nicht auch so funktionieren?
Da passiert kein SEGV, sondern es wird über den normalen Mechanismus ein Signal gesendet. Greif mal spaßeshalber auf einen Nullpointer zu und aus ist's damit.
Hazeh Zimmerer schrieb: > Da passiert kein SEGV, sondern es wird über den normalen Mechanismus ein > Signal gesendet. Greif mal spaßeshalber auf einen Nullpointer zu und > aus ist's damit. Was, wenn nicht ein Null-Pointer-Zugriff, ist denn das:
1 | |
2 | |
Edit: Okay, int* i = NULL wäre vermutlich sauberer, wie hier auch irgendwo im Forum durchdiskutiert wurde.
Ich denke, ich muss mich korrigieren. SEGV ist nicht zwingend fatal und kann von einem Handler abgefangen werden. Man lernt nie aus.
POSIX schreibt das sogar vor. gruß f
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.