error 0x3d0002 arised from file accessing
yueshi
I am using VxWorks 5.5/Tornado 2.2 on Sun-Solaris with PC-Pentium III
target.
When I ran C++ program which involved reading text files on another
Sun-Unix machine (the local ethernet connection is good), the system
gave me error 0x3d0002. This didn't happen all the times, but when
the problem open and read one single file for more than once
consecutively, this kind of error will pop up immediately.
Is error 0x3d0002 about system resource? Do I need to move files to
the VxWorks host machine, or some network configurations are wrong?
Could anybody give some clues on this matter? I am greatly
appreicated to your help.
Yueshi
John
> When I ran C++ program which involved reading text files on another
> Sun-Unix machine (the local ethernet connection is good), the system
> gave me error 0x3d0002. This didn't happen all the times, but when
> the problem open and read one single file for more than once
> consecutively, this kind of error will pop up immediately.
What do you mean by "pop up" in this case? If you mean that the errno
value in the output from 'i' shows this value, then, as always you
should ignore it unless a system function you call actually returns
ERROR.
The errno value being non-zero does not signify an error. It is
information that should only be used when a function you called has
told you that there was an error.
Internally, especially in the networking code, there are a number of
things that can result in errno being set to some value, but that are
handled internally to the routine you called. In this case, if I
remember correctly, the error you are seeing is
S_objLib_OBJ_UNAVAILABLE. That simply means that a system call was
made with a timeout set to NO_WAIT, and the resource, whatever it was,
was not available. For example, semTake (aSemId, NO_WAIT) will
generate this value in errno if the semaphore is not available.
The bottom line is that unless a function you call returns ERROR (or
NULL in cases where that is the indication of a failure condition),
you should ignore the errno value. It is only valid immediately after
a system call returns an error indication to you.
HTH,
John...
=====
Contribute to the VxWorks Cookbook at
http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/WebHome
yueshi
detailedly on this problem here?
> > When I ran C++ program which involved reading text files on another
> > Sun-Unix machine (the local ethernet connection is good), the system
> > gave me error 0x3d0002. This didn't happen all the times, but when
> > the problem open and read one single file for more than once
> > consecutively, this kind of error will pop up immediately.
>
> What do you mean by "pop up" in this case? If you mean that the errno
> value in the output from 'i' shows this value, then, as always you
> should ignore it unless a system function you call actually returns
> ERROR.
>
> The errno value being non-zero does not signify an error. It is
> information that should only be used when a function you called has
> told you that there was an error.
Actually the errno 0x3d0002 was caught by function 'errnoGet()' in the
program somewhere. Then because it detects some error does exist, the
program will run some safety protection routine and exit.
Also I find that the error is caused by VxWorks trying to 'fopen' a
file on another machine (in local network), so I guess error might be
due to heavy traffic load in network.
> Internally, especially in the networking code, there are a number of
> things that can result in errno being set to some value, but that are
> handled internally to the routine you called. In this case, if I
> remember correctly, the error you are seeing is
> S_objLib_OBJ_UNAVAILABLE. That simply means that a system call was
> made with a timeout set to NO_WAIT, and the resource, whatever it was,
> was not available. For example, semTake (aSemId, NO_WAIT) will
> generate this value in errno if the semaphore is not available.
>
> The bottom line is that unless a function you call returns ERROR (or
> NULL in cases where that is the indication of a failure condition),
> you should ignore the errno value. It is only valid immediately after
> a system call returns an error indication to you.
So, to solve the problem, is it possible to change some setting in the
VxWorks configuration to allow the system 'wait' a little bit longer
when accessing files. Or to change the source code, whenever check
'errnoGet', if the result is '0x3d0002', just ignore it? (this way
sounds not very healthy)
Sincerely
Yueshi
Joe Durusau
The bottom line is the code should look something like this:
x = fopen(...)
if (x == (FILE *)NULL)
{
y = errnoGet();
/* do something about whatever the errno was */
}
/* process normally, no error */
/* It is ALWAYS AN ERROR to consult errnoGet() unless a standard */
/* function has returned an indication of error */
If you are checking errnoGet before checking the return value of
whatever function is accessing ther file, you will only get a mess.
Speaking only for myself,
Joe Durusau
Luc
do you reboot your system between file accesses? If no, the remaining
of this message is not related to your problem.
When a connection is established, the client selects a port number. If
I remember well, vxWorks selects a port number starting with a fixed
value upon reset (let's say always 1024). So, the Sun station could
reject a connection request because you always try to use the same port
number.
I don't have a solution for you, some time ago, I asked WRS support to
provide me a way to set the initial port value to a random number at
power up, but I never got a satisfying answer.
In order to determine if it is your type of problem, you should snoop
the ethernet connection to figure out if you try to use always the same
port number when opening the connection. On the sun station, the netstat
command could also help you. On the Sun side, the connection will time
out after a long while (several minutes) and then the port number will
be activated again or, you can reboot your Sun station to re-enable this
port number right now.
Hope it helped!
Luc
Luc Tremblay
TiL Solutions Inc
Consulting services in the embedded/real-time/telecom arena.
--
Luc Tremblay
TiL Solutions Inc.
Consulting services in the embedded/real-time/telecom arena.
Dan Gold
news:3EA55371...@TiLSolutions.com...
> When a connection is established, the client selects a port number. If
> I remember well, vxWorks selects a port number starting with a fixed
> value upon reset (let's say always 1024). So, the Sun station could
> reject a connection request because you always try to use the same port
> number.
This is true, and especially causes havoc when you have remote systems that
come up and try to register with a 'master' or some sort of base station.
If the remote system crashed (or didn't do a clean shutdown) and reboots and
tries to re-register (of course on port 1024), the 'master' will refuse,
until the socket times out.
> I don't have a solution for you, some time ago, I asked WRS support to
> provide me a way to set the initial port value to a random number at
> power up, but I never got a satisfying answer.
You'd need network source to do it. There is a way (hack, workaround), I
think it might even be on the FAQ (if not, it should be). Essentially,
every time you boot, you obtain a random number (reading tbl/tbu on a PPC
for example), and then loop doing a socket/bind/close. This effectively
"eats" up the first N port numbers, then when your application runs, you get
some sort of 'random' port number.
hth,
Dan Gold go...@no-spam.ensemble.com
John
> Actually the errno 0x3d0002 was caught by function 'errnoGet()' in the
> program somewhere. Then because it detects some error does exist, the
> program will run some safety protection routine and exit.
No, you cannot use errnoGet() to determine if there was an error.
> Also I find that the error is caused by VxWorks trying to 'fopen' a
> file on another machine (in local network), so I guess error might be
> due to heavy traffic load in network.
But did fopen() actually return an error status? The value returned by
errnoGet() after a call to fopen() will only be valid if fopen()
itself returned NULL. If the fopen() operation succeeded (i.e. you got
a valid FILE* value back from it), then you should not be checking
errno at all.
> So, to solve the problem, is it possible to change some setting in the
> VxWorks configuration to allow the system 'wait' a little bit longer
> when accessing files. Or to change the source code, whenever check
> 'errnoGet', if the result is '0x3d0002', just ignore it? (this way
> sounds not very healthy)
The question is did the call to fopen() return NULL, or not. If it did
not return NULL then you should not be looking at errno. If, and only
if, fopen() returned NULL should you worry about error handling.
John
> You'd need network source to do it. There is a way (hack, workaround), I
> think it might even be on the FAQ (if not, it should be). Essentially,
> every time you boot, you obtain a random number (reading tbl/tbu on a PPC
> for example), and then loop doing a socket/bind/close. This effectively
> "eats" up the first N port numbers, then when your application runs, you get
> some sort of 'random' port number.
You need to be a bit careful with strategies like this though - each
time you create and then close a socket, you actually hold the
resources for 1 minute past the time of the close operation (2 * MSL).
So, unless you have enough file descriptors and network stack buffers,
this could end up exhausting all the system resources and block. At
the very least it will consume a number of these resources for the
first minute or so of the system's uptime.
You can read a little more about this feature, and configuring the
network stack for improved performance in general in my online book,
but I haven't covered the issue of the ftp port number allocation.
Might have to add a section about that, and possible workarounds (the
best one is to not use ftp based file systems, but for Windows hosts
that's not very easy to avoid - you could use target server FS instead
I guess).
Dan Gold
news:488e459a.03042...@posting.google.com...
> You need to be a bit careful with strategies like this though - each
> time you create and then close a socket, you actually hold the
> resources for 1 minute past the time of the close operation (2 * MSL).
> So, unless you have enough file descriptors and network stack buffers,
> this could end up exhausting all the system resources and block. At
> the very least it will consume a number of these resources for the
> first minute or so of the system's uptime.
Thanks, I should have pointed out that you limit the loop counter to
something reasonable. I've found 16 or 32 is plenty for our purposes. And
of course it's dependent on the frequency of rebooting :-) If you know
that after a few reboots the host will time out and close the socket, the
loop counter can be less.
> You can read a little more about this feature, and configuring the
> network stack for improved performance in general in my online book,
> but I haven't covered the issue of the ftp port number allocation.
It's really not an FTP port number allocation but a generic 'network/socket'
one I believe. Whether a client comes up and wants to TFTP a file (UDP),
FTP something down, or make a TCP connection to a host on a port, it's the
same problem.
> Might have to add a section about that, and possible workarounds (the
> best one is to not use ftp based file systems.
Given the number of vxWorks installations out there, I would think it is
worth mentioning, but not just for FTP apps.
hth,
Dan Gold go...@no-spam.please.ensemble.com
Luc
Maybe one of you is in front of the source code of this stack! The next
port number to use is probably stored in a variable no? Is this variable
global so that it could easily be initialized at power up?
Luc
Luc Tremblay
TiL Solutions Inc.
Consulting services in the embedded/real-time/telecom arena.
John
> It's really not an FTP port number allocation but a generic 'network/socket'
> one I believe. Whether a client comes up and wants to TFTP a file (UDP),
> FTP something down, or make a TCP connection to a host on a port, it's the
> same problem.
IIRC, it affects ftp connections more than rsh ones (this was a common
issue for windoze users of VxWorks AE where multiple files are loaded
at boot time, but was never seen on the unix machines where we all
used rsh instead). That lead me to believe that it must be related,
somehow, to the somewhat unusual way that ftp data connections are
established.
> Given the number of vxWorks installations out there, I would think it is
> worth mentioning, but not just for FTP apps.
I will try to research this issue a little more and see what exactly
are the circumstances when it occurs.
Rgds,
Junichiro Hamaguchi
This is a minor correction though, actual 2MSL varies per TCP
implementations. Recent UNIX-like OS should let you know by
sysctl net.inet.tcp.msl or something like that. John is correct
that VxWorks defines 60 sec as 2MSL like any other BSD derived
OS (see TCPTV_MSL in tcp_timer.h).
FYI - T2.2 version of ftpLib supports PASV. ftpXfer() attempts PASV
mode first, then PORT if failed. Get T2.2 if you are suffering from slow
rebooting over FTP.
HTH,
-hama
yueshi
Thanks a lot for your help. For the ftp server, do you mean I should
use ftp rather than rsh to connect target and host? Sort of getting
confused :))
Anyway, I've made a little bit change on my VxWorks (turned on the ftp
server on host, thus using ftp as the communication between target and
host now). It seems that the system performs differently from before
(a 'less' serious error occurs instead of the previous 0x3d0002), the
details are as below:
------------------------------- Before -------------------------------
architecture: Target <--(rsh)--> Host <--(nfs)--> File server (another
Sun machine where files are read from)
problem: whenever running 'ls' followed by 'i', or 'fopen' followed by
'errorGet()', errno '0x3d0002' (S_objLib_OBJ_UNAVAILABLE) can be
detected
-------------------------------- Now ---------------------------------
architecture: Target <--(ftp)--> Host <--(nfs)--> File server (another
Sun machine where files are read from)
problem: same situation as before, but now we've got errno '0x8800dd'
(S_ftpLib_REMOTE_SERVER_STATUS_221) instead of 'ox3d0002'
----------------------------------------------------------------------
So, I guess the problem lies in some layer lower than communication
protocol, or it's at somewhere between 'Host' and 'File server'.
However, file accessing is actually functioning (files can be read and
written), just I also have those annoying errors at the same time.
Do you have any clue on my situation? I suspect it might be relavent
to new version of VxWorks (I am using VxWorks 5.5)
Also, thanks John, Joe, Luc and Dan. Thank you so much for your
information, but I guess I need a little bit more study to understand
your discussion. There are really a lot of stuff to study for a
VxWorks beginner.
Wish all the best, friends.
Sincerely
Yueshi
Joe Durusau
221 is not an error. It is the server saying goodbye to you. There
is a list of the codes that come back from servers somewhere. You
might try the assigned numbers authority. Sorry, I don't recall
where the list is at the moment.
Junichiro Hamaguchi
I've been missing this thread. Can you show me the operations that
cause this, especially the parameters given to ls and fopen?
As a backend for netDrv, ftp mode is better than rsh mode in my
book, especially the way to aquire ports. There is no passive mode for
rcmd and VxWorks's rcmd consumes certain (and narrow) range of
ports that ends up port starvation much quicker than ftp mode
if you continue creating numerous new sessions over netDrv in short
time period.
In addition, there was a nasty bug in rcmd that was missing a select
call before accept() for the secondary port and the lack caused
infinite waiting within rcmd() by certain rare cases.
Look at the BSD version of rcmd source code in Steven's UNIX
Network Programming first edition (not second edition) that is similar
to VxWorks version of rcmd and you cand find which select call I'm
talking about.
The bug has been fixed in AE1.1 and I believe it has been done in
T2.2 as well.
I heard network application/stack has been improved significantly
in T2.2 so that you may want to check T2.2 out.
HTH,
-hama
Joe Durusau
To the O.P: I may have missed it, but did you ever post the
_reason_ you ran errnoGet()?????
yueshi
Actually I was trying to migrate the software which was originally
written on VxWorks 5.2 to new VxWorks 5.5 version, the ErrnoGet() is
something run every time before activating the motors, so it works as
a kind of safety protection mechanism.
However, it looks like VxWorks 5.5 generates some error number when
'fopen' or 'fclose', while 5.2 doesn't. But this don't affect the
function that it retrieve or dump, I guess perhaps 5.5 monitors error
more carefully? :)
So, I implemented Joe's code, something like
fd = NULL;
fd = fopen(filename, mode);
if (!fd)
// error protection routine
else
{if (errnoGet()==0x3d0002)
errnoSet(0);
}
This method looks a little bit dodgy, and I am not sure what kind of
'side-effect' it will introduce to the whole system, but it works.
Anyway, file accessing will only be done in initialization and won't
affect the real-time control loop, so the above should be an
acceptable solution to my problem I guess.
Do you have any comment on this matter?
Thanks again!
cheers
Yueshi
Joe Durusau
The bottom line is that no routine in any standard library
_has_ to do anything at all with errno unless it is returning an
error to its caller. It is always possible that some routine
that was called internal to a library returned an error, and that
the error was internally dealt with, or that errno was set by
some routine that was called some time ago. The bottom line is
that it is never ever safe to use a sort of watchdog on errno
to determine if there have been any errors. This is a standard
C practice, not just restricted to vxWorks, and causes a lot of
trouble for folks that try checking errno without first checking
whether they have been returned an error by some part of the
system.