Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: wolf_core on July 10, 2012, 01:51:51 AM
-
Hi, I have connected an RS485 to USB converter to TC 3.7.1 + usb-serial- 2.6.33.3-tynycore.tcz and it was recognised as ttyUSB0, but when i run a daemon ( aurora ) that use /dev/ttyUSB0 i have an error.
tc@box :/mnt/sda1/aurora$ ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ Problem locking serial device, can't open lock file: /var/lock/LCK..ttyUSB0 for write.
then i try
tc@box :/mnt/sda1/aurora$ sudo ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ Problem locking serial device, can't write lock file for write: /var/lock/LCK..ttyUSB0.
No such file or directory.
but a LCK..ttyUSB0 file was created in the directory /var/lock/ with inside a PID identifier.
Can you help me. Thanks in advance Luca
PS How i can save the output of console to file, i try with xxxxxx > file.txt but I have only a empty file.txt
-
Hi wolf_core
I think it is complaining because a lock file already exists. Delete it and try again.
PS How i can save the output of console to file, i try with xxxxxx > file.txt but I have only a empty file.txt
I take it by xxxxx you mean the aurora command in this case. See if this works:
sudo ./aurora -a 2 /dev/ttyUSB0 &> file.txtBased on the error messages, I think you are supposed to use sudo.
-
Hi Rich, i have restarted tiny core and there are no files in /var/lock then I launch
tc@box : dmesg | grep usb
tc@box : Kernel command line: initrd=/boot/tinycore.gz waitusb=5:UUID="786D-025A" tce=UUID="786D-025A" quiet BOOT_IMAGE=/boot/bzImage
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
usbcore: registered new interface driver usb-storage
usbcore: registered new interface driver ums-alauda
usbcore: registered new interface driver ums-cypress
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-karma
usbcore: registered new interface driver ums-onetouch
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
usbcore: registered new interface driver berry_charge
usbcore: registered new interface driver appletouch
usbcore: registered new interface driver bcm5974
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
usb 1-1: new low speed USB device using ohci_hcd and address 2
input: LITEON Technology USB Multimedia Keyboard as /devices/pci0000:00/0000:00:0f.4/usb1/1-1/1-1:1.0/input/input2
generic-usb 0003:046D:C312.0001: input: USB HID v1.10 Keyboard [LITEON Technology USB Multimedia Keyboard] on usb-0000:00:0f.4-1/input0
usb 1-2: new low speed USB device using ohci_hcd and address 3
input: Logitech USB-PS/2 Optical Mouse as /devices/pci0000:00/0000:00:0f.4/usb1/1-2/1-2:1.0/input/input3
generic-usb 0003:046D:C03E.0002: input: USB HID v1.10 Mouse [Logitech USB-PS/2 Optical Mouse] on usb-0000:00:0f.4-2/input0
usb 2-2: new full speed USB device using ohci_hcd and address 2
scsi0 : usb-storage 2-2:1.0
usb 2-1: new full speed USB device using ohci_hcd and address 3
usbcore: registered new interface driver usbserial
usbcore: registered new interface driver usbserial_generic
usbserial: USB Serial Driver core
usb 2-1: pl2303 converter now attached to ttyUSB0
usbcore: registered new interface driver pl2303
the adapter RS485 to USB (pl2303) was recognised and ttyUSB0 was created and seems OK
tc@box :/mnt/sda1/aurora$ sudo ./aurora -a 2 /dev/ttyUSB0
tc@box :/mnt/sda1/aurora$ 20120710-23:31:06: aurora: Problem locking serial device, can't write lock file: /var/lock/LCK..ttyUSB0.
No such file or directory
same error :-( , and if I disconnect the adapter the error don't change
Thanks Luca
-
Hi wolf_core
I decided to take a look at the source code to see if I could figure out what the program is complaining about. I noticed
that the author was misusing the errno variable. Open the file called main.c and find the phrase:
|| errno_save != 0Remove all three instances of that phrase, not he whole line, just that exact phrase. Recompile the program and
see if it behaves any better.
-
Ty Rich, your patch seems correcting the problem ;D . Now I try to connect the adapter to RS485 port of Photovoltaic inverter and I hope i can read the data.
Thanks a lot Luca
-
Hi wolf_core
Yeah, I had a feeling it might help. Except for a few special cases, errno should not be used to see if an error
occurred, that's what the return value of a function is for. Let us know how you make out.
-
Hi wolf_core
I decided to take a look at the source code to see if I could figure out what the program is complaining about. I noticed
that the author was misusing the errno variable. Open the file called main.c and find the phrase:
|| errno_save != 0
Remove all three instances of that phrase, not he whole line, just that exact phrase. Recompile the program and
see if it behaves any better.
Rich, explain to me how these three statements, as you put it, was misusing the errno variable?
if (bWrite < 0 || errno_save != 0) {
if (bWrite < 0 || errno_save != 0) {
if (bWrite < 0 || errno_save != 0) {
According to the errno(3) - Linux man page
"Valid error numbers are all nonzero; errno is never set to zero by any system call or library function. "
So what the above code is doing is that if fprintf() or fscanf() had a problem bWrite will indicate that and we don't even care what errno is because we don't even check it then at that point. But, if for some reason errno is *not* zero which should not happen without an error actually occurring as indicated by the function(s) return code, I want to know about it. Because that is not right.
I appreciate you bringing this to my attention but I wish wolf_core would have contacted me directly. I fear the problem may lie elsewhere and I'd rather get to the root cause.
What I suspect here is that errno_save is not zero because on the system in question errno is not initialized to zero. I'd like to confirm that and address that. This does not happen on other distributions that I know of.
I'd like to see the debug output from aurora when this occurs by using the -b option as the first option on the line. wolf_core if you can go back to the original code and do that and send it to me directly I'm more then willing to figure out what's going on and make any corrections necessary.
-The author of aurora...
-
Or... It looks like that routine and main are the *only* places I forgot to initialize errno to zero *and* the system doesn't do it either. Which would explain why it does not happen in other distributions...
Or... On this distribution for some reason errno *is* set to non-zero if the library call is successful which would not be right either.
Or... By the fact I forgot to initialize it to zero it has what ever that memory location happened to have. But the system should not allow that, that is a big security risk.
Would like to get to the bottom of this.
-
IIRC no standard requires the system to initialize errno. It's always the app's responsibility.
-
I am sorry to have created this misunderstanding :-[ .
I want to thanks all the members of tiny core forum and also the author of aurora for the aurora daemon. Yes Blankman, I have an original compiled file an i will send the debug result.
Thanks again Luca
-
IIRC no standard requires the system to initialize errno. It's always the app's responsibility.
Yeah but it's IMO bad security practices not to initialize variables, allows for memory trolling with crafted use, on a interactive system, not real good. Unless it's being randomized, that's ok too, but that is not known.
Granted my fault for overlooking initializing it in two spots so I'm happy this was brought to my attention, but I would think that since it's from an include file that it would/should maybe be taken of. By the fact I haven't run into it in other distros leads me to believe it is.
Funny thing too, I usually see a compile warning, variable used without being initialized when that occurs, but not in this case. Now that 'm thinking about it that may only be when used in a conditional test and errno is not used that way directly.
-
Just did a quick test on openSuse 11.4 in the routine in question and it appears even though I do not initialize it there errno is set to zero.
Looks like Luca had two issues here the open then the write. To get the open error the file pointer would need to be returned NULL.
Luca, when that happened did the /var/lock directory exist?
Also, were you running aurora as root or as a user with lesser privileges?
Looks like you were running it out of the directory it was compiled in before doing a 'make install' which sets the proper privileges on the binary for non root users to use aurora.
I'm going to have to look at that too.
-
Hi Blankman
In hindsight, "misusing" was a poor choice of words on my part since it suggests intent, and that was not my intent.
From http://www.kernel.org/doc/man-pages/online/pages/man3/errno.3.html
The <errno.h> header file defines the integer variable errno, which is set by
system calls and some library functions in the event of an error to indicate
what went wrong. Its value is significant only when the return value of the
call indicated an error (i.e., -1 from most system calls; -1 or NULL from most
library functions); a function that succeeds is allowed to change errno.
Valid error numbers are all nonzero; errno is never set to zero by any system
call or library function.
Note the phrases "a function that succeeds is allowed to change errno" and "errno is never set to zero by any system
call or library function". That says that even a successful call to function can return a nonzero value for errno.
There really is no good reason to use errno to test if an error occurred, however, if you really feel you must, you should
probably change the || to && in your if statement.
-
Hi Blankman, yes the directory /var/lock/ exist (no files inside) and i run the daemon with the command
tc@box:/mnt/sda1/aurora$ sudo ./aurora -b -a 2 -e /dev/ttyUSB0the daemn return the error but the LCK..ttyUSB0 file was created in the directory /var/lock/ with inside a PID identifier.
The directory /mnt/sda1/aurora isn't the directory where i compiled the daemon but another directory. I have sent the debug msg by mail.
Thanks Luca
-
Hi wolf_core
I am sorry to have created this misunderstanding
You did not create any misunderstanding. I emailed a link of this thread to the author and that started an
exchange of ideas.
-
Rich, yes, on success a function is allowed to alter errno, but to the best of my knowledge there are no values for errno for the functions used in aurora that do not indicated that some sort of a problem occurred. But if a function returns success but errno has been set to something, I want to know about it. That's an "or" not an "and".
And, in those instances I am checking for the unexpected, if something is returned that I do not expect, I want to know about it. If the function returns a negative then errno should be a non-zero number. If the function returns a 0 (zero) errno should be 0 also, if it isn't I want to look into why. My oversight in two places was that I didn't first initialize errno to 0.
I am thorough and meticulous, I check for everything I can think of and that of course is still not all encompassing.
Where I used to work we had a programer that prided himself on being a Mensa member and knew everything so he only checked for error codes returned that he thought could be returned, anything outside of what he thought could be returned he considered success. Well one day an error was returned that he thought would never be returned and the program just kept chugging along. For quite a while until someone noticed anomalies in reports. Turns out the code landed up populating 500,000 rows into a production DB that was used for FDA reporting. Needless to say that had to be cleaned up creating a lot of work.
My philosophy is that if something occurs that is not expected to occur, stop right there and evaluate why it occurred. That is what those checks are doing, and it worked. errno is not expected to be non-zero at that point when the function returns zero so that will be corrected even though it was caused by the code itself. So the error is that errno is not initialized and to me that is an error in the code that will be addressed.
*If* in the future a function returns success but also returns a non-zero errno by design I will be able to evaluate it and if deemed OK then code an exception. Meanwhile, it won't possibly be sitting there chugging along fat dumb and happy while corrupting data that then has to be cleaned up or worse yet is lost for an extended period of time because an exception wasn't thrown.
It brought to light that this distro operates differently then others, no big deal. Would have never come to light even here had it not been for my oversight.
This comes down to coding philosophy. Call it overkill, but I code on the side of caution.
-
Rich, yes, on success a function is allowed to alter errno, but to the best of my knowledge there are no values for errno for the functions used in aurora that do not indicated that some sort of a problem occurred.
Well, that's the deal: the standard allows a function to set errno to an error condition despite successing. One should only check errno if an error was returned, just like Rich said.
Consider for example a library function that can only set errno to EACCESS. It might be optimized to always set errno to EACCESS, and only report the status via its error code. This would be entirely "legal" by the standard.
-
Hi Blankman
Quoting once again from the manual:
Its value is significant only when the return value of the call indicated an error
Now, unless the documentation for one of the functions you are calling contradicts this, which some do, you are
checking the value of something which has no meaning and making a decision based on that test. What you are
doing in this case is not defensive programming, rather, checking to see that undefined behavior always
behaves the same way, from one system to the next, and ready to start coding exceptions when it doesn't.
-
curaga, the standard allows errno to be set by a function on success, your assumption, that it's a error condition assumes facts not in evidence. Just because the variable is named errno may not mean it has to be an error, traditionally that's what it is but who knows, someday it could be an extended condition.
Oh and ah, if you're referring to EACCES, that is a bona fide error. If something returns that and an errno then a decision will have to be coded based on that that decides whether or not to continue. Which is basically what I've been saying all along, a decision on what to do would have to be coded.
Rich, yep, but that is today, but who knows about tomorrow, unless you can see the future. I've got bit a number of times by function call changes from one library version to the next. If I take steps to check things what's it to you? And you said I'm 'checking to see that undefined behavior always behaves the same way', not even close, since functions are allowed to alter errno I'm checking to see if a defined behavior has occurred. Once again for the functions in use that does not occur but I'll say again, that is today.
You guys want to stay in that box that's fine, if I choose to think outside that box that should be fine too.
-
Oh yeah, I released version 1.8.3 of aurora to correct the issue Luca discovered, and yes, I'm still checking errno the same way as before.