what's objLib?
Wang,Xiaoguang(Freeman)
module #3d means objLib. But I can't find that lib in ref_manual of vxWorks.
What's that lib?
Thanks
Werner Schiendl
there you'll find
#define S_objLib_OBJ_ID_ERROR (M_objLib | 1)
#define S_objLib_OBJ_UNAVAILABLE (M_objLib | 2)
So 0x3d0001 means you pass an invalid system object handle to VxWorks at
some place. This can be a semaphore, message queue, and other things. I
would consider this a problem that should be solved.
0x3d0002, AFAIK, just means that a resource could not be aquired, when you
specified NO_WAIT as a timeout. If that task uses such thing (or some
functions used by your software do so) this does not mean an error.
hth
werner
Wang,Xiaoguang(Freeman) <freema...@marconi.com> wrote in message
news:98ldn6$s7r$1...@newsfeed.pit.comms.marconi.com...
Wang,Xiaoguang(Freeman)
Your answer is more than I expected :)
Thanks a lot.
Werner Schiendl <ws-...@gmx.at> wrote in message
news:98451866...@newsmaster-04.atnet.at...
Dave Korn
>> news:98ldn6$s7r$1...@newsfeed.pit.comms.marconi.com...
>> > When I show task information. I got ERRNO of 3d0001 and 3d0002. Then I
>> found
>> > module #3d means objLib. But I can't find that lib in ref_manual of
>> vxWorks.
>Werner Schiendl <ws-...@gmx.at> wrote in message
>news:98451866...@newsmaster-04.atnet.at...
>> lookup $(WIND_BASE)/target/h/objLib.h
>>
>> there you'll find
>>
>> #define S_objLib_OBJ_ID_ERROR (M_objLib | 1)
>> #define S_objLib_OBJ_UNAVAILABLE (M_objLib | 2)
It is probably also worth mentioning that you can ignore this error: it
happened way down in the kernel somewhere, and was dealt with by the kernel.
This is because errno gets set when an error occurs, but is never cleared:
it only ever gets set to a new value when a new error happens.
The value of errno is only valid immediately after you get an ERROR code
returned from some kernel function. If the function returns OK, errno might
or might not have a value in it, but you *must* ignore it.
It isn't important, but I *think* that the 0x3d0001/2 error happens
somewhere deep in the inner levels of ioLib.
DaveK
--
They laughed at Galileo. They laughed at Copernicus. They laughed at
Columbus. But remember, they also laughed at Bozo the Clown.
Keith Arner
> The value of errno is only valid immediately after you get an ERROR
> code returned from some kernel function. If the function returns OK,
> errno might or might not have a value in it, but you *must* ignore it.
>
> It isn't important, but I *think* that the 0x3d0001/2 error happens
> somewhere deep in the inner levels of ioLib.
In my experience, 0x3d0002 is normal. Something did a semTake() with a
timeout. However, 0x3d0001 is usually a sign of something having gone
wrong -- you passed a pointer to something, but have lost track of the
state of that something. For example, if two tasks are sharing a SEM_ID,
and one of the tasks attempts to semTake() that SEM_ID after the other has
done a semDelete(), you are going to get 0x3d0001.
As you said, you need to catch errno at the point of return from a system
call, so tracking it down after you see it appear in the output of
i() is a waste of time. However, it's probably worth the effort to figure
out why you are getting 0x3d0001 in the first place.
Keith
--
Wang,Xiaoguang(Freeman)
I've found one bug in the code. When a device was created, the
SEL_WAKEUP_LIST structure was not initialized by selWakeupListInit(). Thus
causes 3d0001 reported when select() was called.
I think I need to figure out all the causes of errno 3d0001 by debugging
into the system code.
As for errno 3d0002, I agree that it's not very important, but do you think
it's normal if I can't clear it with errnoOfTaskSet()? I mean it seems that
that error was set again right after I cleared the errno variable.
It makes me very unhappy because it's not a desired behaviour. After
checking the code, I found that all possible calls with time_out value
NO_WAIT are msgQSend calls. I guess maybe some task which is not well
synchronized is sending msgs in a loop.
Thank you very much for your help.
Xiaoguang
Keith Arner <kar...@fore.com> wrote in message
news:Pine.GSO.4.20.0103190945570.6196-100000@zimbra...
Keith Arner
> I've found one bug in the code. When a device was created, the
> SEL_WAKEUP_LIST structure was not initialized by selWakeupListInit(). Thus
> causes 3d0001 reported when select() was called.
>
> As for errno 3d0002, I agree that it's not very important, but do you think
> it's normal if I can't clear it with errnoOfTaskSet()? I mean it seems that
> that error was set again right after I cleared the errno variable.
If you check errno immediately after you set it, it should not have
changed. If you make any system calls between the time you set it and the
time you test it, all bets are off.
> It makes me very unhappy because it's not a desired behaviour. After
> checking the code, I found that all possible calls with time_out value
> NO_WAIT are msgQSend calls. I guess maybe some task which is not well
> synchronized is sending msgs in a loop.
My guess is that select() is setting errno to 3d0002. After all, it will
sleep against a semaphore for the timeout that you specify. If you don't
have activity on any fd before the timeout, you will get 3d0002.
Keith
James Marshall
> > checking the code, I found that all possible calls with time_out value
> > NO_WAIT are msgQSend calls. I guess maybe some task which is not well
> > synchronized is sending msgs in a loop.
>
> My guess is that select() is setting errno to 3d0002. After all, it will
> sleep against a semaphore for the timeout that you specify. If you don't
> have activity on any fd before the timeout, you will get 3d0002.
Not quite true. There's a subtle difference in VxWorks that's already caught us
out. If you semTake() with NO_WAIT and the semaphore isn't available then you get
3d0002, _OBJ_UNAVAILABLE. semTake() with a non-zero timeout which expires before
the semaphore is available returns 3d0004, OBJ_TIMEOUT. In other words it's only
a timeout if you asked to wait, otherwise it's just unavailable.
I expect the behaviour is the same for message queues - and select() if it uses
semaphores.
James Marshall.
Wang,Xiaoguang(Freeman)
then...
Now, I've found what caused errno 3d0001 in some other tasks, tShell and
another task. Here is my question before I dig deeper into the code :
The function generates 3d0001 is printf().
I have no console contact to the target. I have to telnet to it. When I
check its stdin/stdout/stderr, all of them point to fd=5. I'm using vxWorks
5.3.1-arm, is anything wrong with WRS's telnet module? Is this errno
acceptable when I use telnet?
It seems to me that the semaphore for the device which telnet is using has
some problem. Is it a pty? Should it be initialized by WRS?
Thanks
Freeman
James Marshall <james_m...@agilent.com> wrote in message
news:3AB8A249...@agilent.com...
Joe Durusau
it shouldn't? If so, which one?
Speaking only for myself,
Joe Durusau
Wang,Xiaoguang(Freeman)
passed a timeout value of 0. So it should set the errno when it tries to
take a semaphore, just as Keith said.
Actually, it's not exactly a function returning ERROR, it's a function
setting ERRNO. There is no NULL.
I think 3d0001 is an errno which shouldn't happen, but it seems 3d0002 is
acceptable or inevitable if you try to access to a system object but don't
want to wait.
Joe Durusau <joseph.a...@lmco.com> wrote in message
news:3AB91244...@lmco.com...
Joe Durusau
errno when a function has not returned an indication of error.
On my system, the man page for select says in part:
RETURNS
The number of file descriptors with activity, 0 if timed
out, or ERROR if an error occurred when the driver's
select() routine was invoked via ioctl().
If select is returning 0, it has timed out, no error has occurred,
and this circumstance, errno IS WITHOUT MEANING AND SHOULD NOT BE READ!!
Note that the correct sequence of events is:
call some function
look at the return value
if ERROR
{
read errno, do something about it
}
else
drive ON, and ignore errno
Dave Korn
<99db1g$s61$1...@newsfeed.pit.comms.marconi.com>...
>
>Actually, it's not exactly a function returning ERROR, it's a function
>setting ERRNO. There is no NULL.
If there is no ERROR returned from a function, THE VALUE OF ERRNO IS
INVALID AND COMPLETELY MEANINGLESS AND YOU ****MUST**** IGNORE IT.
Really. You're just wasting your time and everyone else's with
speculating about the internals of the OS. If you care that much, buy a
source code license and you can see what's going on. But really, don't.
Just don't. The errno variable only has meaning in the context of a system
call returning an error indication; in those circumstances, and ONLY in
those circumstances, the value of errno indicates *which* error ocurred.
You might as well waste your time trying to make sense of the values of
random memory locations.
Wang,Xiaoguang(Freeman)
Thanks for your advice.
But why did you think it's 'about the internals of the OS'? I never
questioned the vxWorks, at least till now.
The problem is : select(), printf() will call the underling device drivers
written by somebody other than WRS. In my case, the device driver was
written by my colleagues. And I have found something wrong in the device
driver. For example, if you didn't call selWakeupListInit() in xxDevCreate()
before you call select, then you'll get an errno 0x3d0001.
And I can't agree with you about the meaning of errno. As per my
understanding, vxWorks reserved some of the module IDs, but anyone else can
creat their own errnos and use them in their code freely to help tracking
some problems. Not only system call. And what's the concept of system call
here?
Could you tell me more about
> values of
> random memory locations.
Thanks
Xiaoguang
Dave Korn <no....@my.mailbox.invalid> wrote in message
news:YmHu6.332$UG4....@newsr1.u-net.net...
Keith Arner
> If there is no ERROR returned from a function, THE VALUE OF ERRNO IS
> INVALID AND COMPLETELY MEANINGLESS AND YOU ****MUST**** IGNORE IT.
I think that you and I are arguing this issue from two different
standpoints. From a purely programatic perspective, it is indeed
pointless to test the value of errno at random times during
execution. The only time that errno is guaranteed to have a meaningful
value is immediately after a system call returns an error.
However, from a debugging perspective, it is often useful to occasionally
take a peek at errno to see if it has a value that you cannot
explain. The fact of the matter is, things do not set errno at
random... they only do so to indicate that which error occured.
As an example, I recently had to debug a problem where many of the tasks
in our system went haywire. I noticed that one of them had errno
0xd0003. This errno is S_iosLib_INVALID_FILE_DESCRIPTOR. I was able to
conclude that that task had somehow gotten confused about what fds it was
supposed to be operating on, and eventually chased it down to a
double close. If I hadn't had that clue, I would probably still be
staring at source code.
> Really. You're just wasting your time and everyone else's with
> speculating about the internals of the OS. If you care that much, buy a
> source code license and you can see what's going on. But really, don't.
> Just don't. The errno variable only has meaning in the context of a system
> call returning an error indication; in those circumstances, and ONLY in
> those circumstances, the value of errno indicates *which* error ocurred.
This brings me to an important point. I do have the "luxury" of a source
license. Without it, I would not be able to draw the conclusion that
0x3d0001 only occurs if something is confused about what object it is
operating on, and is therefore necessarily indicative that there was a
real problem at one time. I'm of the opinion that people without a source
license are at a serious disadvantage (this statement is not VxWorks
specific).
> You might as well waste your time trying to make sense of the values of
> random memory locations.
But errno is better than random. If it is set, you know that something at
some point was reporting that error (assuming that some malicious coder
isn't just setting it out of spite). It's not a foolproof way of catching
problems, but chasing down the source of errnos that you cannot explain is
often a useful exercise.
Keith
Werner Schiendl
> understanding, vxWorks reserved some of the module IDs, but anyone else
can
> creat their own errnos and use them in their code freely to help tracking
> some problems. Not only system call. And what's the concept of system call
> here?
Yes and No: Yes, you can define your own values for errno and use it to pass
the details of an error happening in your libraries (or application) to the
calling function. But No, the value of errno is valid ONLY, is the called
function returned an indication of an error. If the function completed
successfully there is no need to care about an error value. This is why Dave
said these were OS internals: Maybe the OS tries some call and handles the
error condition internally. It will not clear errno to 0 - you never will -
for efficiency's sake and because its useless.
>
> Could you tell me more about
> > values of
> > random memory locations.
>
Errno is only set to a valid error code IF an error occured. Otherwise
anything may be in there.