Toon posts:

ttyS1 hangt na 10 keer openen

Pagina: 1
Acties:

Verwijderd

Topicstarter
Goed, ik heb een programmaatje dat de seriele poort ttyS1 opent en wat ermee doet (pins aansturen met ioctl of tcsetattr) in een while(1) lus. Met ctrl-c sluit ik het programma af. En nog een keer opstarten, gaat goed. Weer ctrl-c. Enzovoort. Maar na een tijdje werkt het niet meer.

Ik denk dat dat komt doordat close(fd) niet wordt uitgevoerd na ctrl-c en dat hier en daar wat buffers enzo open blijven. Hoe kan ik ze toch sluiten zonder in de while lus steeds de invoer te checken?

Of wat ik eigenlijk ook zoek, met root alle open sessies van ttyS1 afsluiten zodat er weer nieuwe kunnen worden gemaakt. Hoef ik niet meer te rebooten :-)

  • serkoon
  • Registratie: April 2000
  • Niet online

serkoon

mekker.

Alle filedescriptors zouden gesloten moeten worden bij het doodgaan van een proces. Als dat niet gebeurt heb je een bug (in de kernel, that is) :)

Misschien dat je wat meer duidelijkheid kan krijgen waar het aan ligt als je een trace doet van je proces, met trace, truss, ktrace of strace (en er zullen vast nog meer zijn)..

[ Voor 4% gewijzigd door serkoon op 07-04-2003 12:26 ]


Verwijderd

Met shellcode zou je een trap aanmaken voor ^C. In die trap kun je vervolgens de file descriptors sluiten. In andere talen komt het erop neer dat je het ^C signaal moet afvangen, en daar een handler aan moet koppelen.

Verwijderd

Topicstarter
Oke, het is opgelost! In de oude versie stracen: geen close(fd) terwijl ik toch wel een nieuwe kernel gebruik (2.4.20 van RedHat9 die pas een paar dagen uit is).
Met een signal(SIGINT,doquit) waarin doquit de endless loop stopt, wordt fd wel gesloten (in strace te zien). Nu nog wat meer in/outs maken mbv 4094 en 4021...

  • deadinspace
  • Registratie: Juni 2001
  • Laatst online: 02-05 18:38

deadinspace

The what goes where now?

close() wordt ook niet voor strace zichtbaar aangeroepen als een process een SIGINT krijgt. Als een process SIGINT krijgt wordt afaik _exit() aangeroepen, en de kernel handelt dan alle dingen af, waaronder het sluiten van filedescriptors.

Bleven processes niet toevallig hangen ofzo? Dat ze niet helemaal afsloten en dus de filedescriptor in gebruik hielden?