From: Chris P. <par...@ie...> - 2007-03-15 22:35:22
|
Hey all. I was testing a serial i/o program that I am writing today, and I killed it with a control-C. The next time I went to run it, I got the error "Bad file descriptor" when I tried to write to ttyS2 (I was able to open a file descriptor for ttyS2, though...). Rebooting the gumstix made no difference. I should point out that I was being stupid and running my code as root. How should I fix this? There is the brute-force solution of reflashing the filesystem, but I would prefer a more elegant solution, if there is one. thanks, -Chris |
From: Dave H. <dhy...@gm...> - 2007-03-16 00:23:50
|
Hi Chris, On 3/15/07, Chris Parker <par...@ie...> wrote: > Hey all. I was testing a serial i/o program that I am writing > today, and I killed it with a control-C. The next time I went to run > it, I got the error "Bad file descriptor" when I tried to write to > ttyS2 (I was able to open a file descriptor for ttyS2, though...). > Rebooting the gumstix made no difference. I should point out that I > was being stupid and running my code as root. How should I fix > this? There is the brute-force solution of reflashing the > filesystem, but I would prefer a more elegant solution, if there is one. Was your open successful? Or did it return a negative number? Can you post your code? Sorry to say it, but "bad file descriptor" sounds like a bug in your code :) -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Chris P. <par...@ie...> - 2007-03-16 15:53:04
Attachments:
serial3.c
|
Ok, this looks bad on me. I've gotten rid of the problem, but it was bizarre. My function that opens the port worked just fine; I was gtting 3 for a file descriptor for ttyS2. I traced the bizarreness to an sprintf statement that didn't contain any reference to fd, my int that held the file descriptor. Somehow, printing to a string was corrupting my serial port file descriptor. I had a formatting instruction out of order. What I wanted was to print an integer as a 4-digit hexidecimal padded with zeros on the left when the number was less than 4 digits long. Here is the troublesome statement: sprintf(message, "(V0%40X)", speed); I noticed this morning that it should be: sprintf(message, "(V0%04X)", speed); That is, the '0' to cause left-zero-padding needs to be before the width specifier, not after. message is a 20-byte char array and speed is an int. How this corrupted my file descriptor for ttyS2 is beyond me, but I'd love to know! -Chris Dave Hylands wrote: > Hi Chris, > > On 3/15/07, Chris Parker <par...@ie...> wrote: > >> Hey all. I was testing a serial i/o program that I am writing >>today, and I killed it with a control-C. The next time I went to run >>it, I got the error "Bad file descriptor" when I tried to write to >>ttyS2 (I was able to open a file descriptor for ttyS2, though...). >>Rebooting the gumstix made no difference. I should point out that I >>was being stupid and running my code as root. How should I fix >>this? There is the brute-force solution of reflashing the >>filesystem, but I would prefer a more elegant solution, if there is one. > > > Was your open successful? Or did it return a negative number? > > Can you post your code? > > Sorry to say it, but "bad file descriptor" sounds like a bug in your code :) > |
From: Tim N. <ce...@gm...> - 2007-03-16 16:29:24
|
There are some cool things you can do with sprintf for buffer overflow exploits and running arbitrary code... I will posit a guess that your file descriptor just happened to be in the right place for your padding to go beyond the 20 char limit and write information into its memory area. If I am reading that right it would have been a 40 character padding right? That's just a guess though. --Tim On Fri, 16 Mar 2007 9:21, Chris Parker wrote: > Ok, this looks bad on me. I've gotten rid of the problem, but it was > bizarre. My function that opens the port worked just fine; I was > gtting 3 for a file descriptor for ttyS2. I traced the bizarreness to > an sprintf statement that didn't contain any reference to fd, my int > that held the file descriptor. Somehow, printing to a string was > corrupting my serial port file descriptor. I had a formatting > instruction out of order. What I wanted was to print an integer as a > 4-digit hexidecimal padded with zeros on the left when the number was > less than 4 digits long. Here is the troublesome statement: > > sprintf(message, "(V0%40X)", speed); > > I noticed this morning that it should be: > > sprintf(message, "(V0%04X)", speed); > > That is, the '0' to cause left-zero-padding needs to be before the > width specifier, not after. message is a 20-byte char array and speed > is an int. How this corrupted my file descriptor for ttyS2 is beyond > me, but I'd love to know! > > -Chris > > > Dave Hylands wrote: >> Hi Chris, >> On 3/15/07, Chris Parker <par...@ie...> wrote: >> >>> Hey all. I was testing a serial i/o program that I am writing >>> today, and I killed it with a control-C. The next time I went to run >>> it, I got the error "Bad file descriptor" when I tried to write to >>> ttyS2 (I was able to open a file descriptor for ttyS2, though...). >>> Rebooting the gumstix made no difference. I should point out that I >>> was being stupid and running my code as root. How should I fix >>> this? There is the brute-force solution of reflashing the >>> filesystem, but I would prefer a more elegant solution, if there is >>> one. >> >> Was your open successful? Or did it return a negative number? >> Can you post your code? >> Sorry to say it, but "bad file descriptor" sounds like a bug in your >> code :) >> --Tim |
From: Dave H. <dhy...@gm...> - 2007-03-16 16:58:48
|
Hi Chris, On 3/16/07, Chris Parker <par...@ie...> wrote: > nevermind. I realize now (thanks to one of my labmates) that > sprintf(message, "%40X", speed) tries to print a 40 character hex, and > that I was overrunning the size of message, which is only 20 bytes. I > should have been using snprintf()! Ahh yes. sprintf, strcpy, and strcat should all be considered evil functions and never show up in your code. Even strncpy and strncat have some subtle nasty behaviours. The strlcpy and strlcat functions included with the kernel are implemented the way that strncat and strncpy should have been implemented. You can examine the implementation of strlcpy and strlcat in linux/lib/string.c, for those that are interested. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |
From: Alex F. <kb...@gm...> - 2007-03-16 00:28:21
|
On Thursday 15 March 2007 19:35, Chris Parker wrote: > Hey all. I was testing a serial i/o program that I am writing > today, and I killed it with a control-C. The next time I went to run > it, I got the error "Bad file descriptor" when I tried to write to > ttyS2 (I was able to open a file descriptor for ttyS2, though...). You're opening /dev/ttyS2, right? |
From: Chris P. <par...@ie...> - 2007-03-16 16:23:03
|
nevermind. I realize now (thanks to one of my labmates) that sprintf(message, "%40X", speed) tries to print a 40 character hex, and that I was overrunning the size of message, which is only 20 bytes. I should have been using snprintf()! Chris Parker wrote: > Ok, this looks bad on me. I've gotten rid of the problem, but it was > bizarre. My function that opens the port worked just fine; I was gtting > 3 for a file descriptor for ttyS2. I traced the bizarreness to an > sprintf statement that didn't contain any reference to fd, my int that > held the file descriptor. Somehow, printing to a string was corrupting > my serial port file descriptor. I had a formatting instruction out of > order. What I wanted was to print an integer as a 4-digit hexidecimal > padded with zeros on the left when the number was less than 4 digits > long. Here is the troublesome statement: > > sprintf(message, "(V0%40X)", speed); > > I noticed this morning that it should be: > > sprintf(message, "(V0%04X)", speed); > > That is, the '0' to cause left-zero-padding needs to be before the width > specifier, not after. message is a 20-byte char array and speed is an > int. How this corrupted my file descriptor for ttyS2 is beyond me, but > I'd love to know! > > -Chris > > > Dave Hylands wrote: > >> Hi Chris, >> >> On 3/15/07, Chris Parker <par...@ie...> wrote: >> >>> Hey all. I was testing a serial i/o program that I am writing >>> today, and I killed it with a control-C. The next time I went to run >>> it, I got the error "Bad file descriptor" when I tried to write to >>> ttyS2 (I was able to open a file descriptor for ttyS2, though...). >>> Rebooting the gumstix made no difference. I should point out that I >>> was being stupid and running my code as root. How should I fix >>> this? There is the brute-force solution of reflashing the >>> filesystem, but I would prefer a more elegant solution, if there is one. >> >> >> >> Was your open successful? Or did it return a negative number? >> >> Can you post your code? >> >> Sorry to say it, but "bad file descriptor" sounds like a bug in your >> code :) >> > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > ------------------------------------------------------------------------ > > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Chris P. <par...@ie...> - 2007-03-16 17:41:42
|
And for those of you interested (as I was...), here is a link to the paper from the OpenBSD project on strlcat() and strlcpy(): www.openbsd.org/papers/strlcpy-paper.ps -Chris Dave Hylands wrote: > Hi Chris, > > On 3/16/07, Chris Parker <par...@ie...> wrote: > >>nevermind. I realize now (thanks to one of my labmates) that >>sprintf(message, "%40X", speed) tries to print a 40 character hex, and >>that I was overrunning the size of message, which is only 20 bytes. I >>should have been using snprintf()! > > > Ahh yes. > > sprintf, strcpy, and strcat should all be considered evil functions > and never show up in your code. > > Even strncpy and strncat have some subtle nasty behaviours. > > The strlcpy and strlcat functions included with the kernel are > implemented the way that strncat and strncpy should have been > implemented. > > You can examine the implementation of strlcpy and strlcat in > linux/lib/string.c, for those that are interested. > |
From: Dave H. <dhy...@gm...> - 2007-03-16 18:53:08
|
Hi Chris, On 3/16/07, Chris Parker <par...@ie...> wrote: > And for those of you interested (as I was...), here is a link to the > paper from the OpenBSD project on strlcat() and strlcpy(): > www.openbsd.org/papers/strlcpy-paper.ps Thanks for the pointer on that very well written writeup. I put a PDF version over here: http://www.davehylands.com/gumstix-wiki/strlcpy-paper.pdf -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ |