We are getting file write errors where the perror is ‘bad file
descriptor’. The return code from the write is -1.
When we printf the file descriptor before and after the write, it
appears to be ok.
We have created 2 tasks that use the same Base class.
FileManager is the base class. It handles the file open, close,
create.
In the first task (LogTask), there are 2 classes that are derived from
FileManager.
Each of these classes opens a file and leaves it open for write. The
file descriptors for these are 4 and 5.
In the second task (DataTask), FileManager is the base for
RecordManager, and RecordManager is the base for User, Patient, Session
and Spectral.
Each of these classes opens a file as well.
The DataManager also opens and closes a file (Unique) with a local file
descriptor. It uses file descriptor 4.
User opens a file and then closes it. It uses file descriptor 4.
Patient opens a file and then closes it. It uses file descriptor 4.
Session opens a file and leaves it open. It uses file descriptor 4.
Spectral opens a file and leaves it open. It uses file descriptor 5.
Spectral will get an error writing to the file at various times. It
may happen quickly, or it may take many writes to get the error. It is
writing a record of the same length each time.
When printing the file descriptor before and after the write, it is 5
before and 5 after.
The perror is ‘bad file descriptor’. The return code from the write
is -1.
If you have seen this problem, or have any ideas why this is occuring,
please let me know.
Regards,
Becki
“Becki Drury” <bdrury@softwareremodeling.com> wrote in message
news:3A5B3FA5.FB548308@softwareremodeling.com…
We are getting file write errors where the perror is ‘bad file
descriptor’. The return code from the write is -1.
When we printf the file descriptor before and after the write, it
appears to be ok.
We have created 2 tasks that use the same Base class.
Does tasks == threads ? If so file descriptor cannot be shared
across threads.
FileManager is the base class. It handles the file open, close,
create.
In the first task (LogTask), there are 2 classes that are derived from
FileManager.
Each of these classes opens a file and leaves it open for write. The
file descriptors for these are 4 and 5.
In the second task (DataTask), FileManager is the base for
RecordManager, and RecordManager is the base for User, Patient, Session
and Spectral.
Each of these classes opens a file as well.
The DataManager also opens and closes a file (Unique) with a local file
descriptor. It uses file descriptor 4.
User opens a file and then closes it. It uses file descriptor 4.
Patient opens a file and then closes it. It uses file descriptor 4.
Session opens a file and leaves it open. It uses file descriptor 4.
Spectral opens a file and leaves it open. It uses file descriptor 5.
Spectral will get an error writing to the file at various times. It
may happen quickly, or it may take many writes to get the error. It is
writing a record of the same length each time.
When printing the file descriptor before and after the write, it is 5
before and 5 after.
The perror is ‘bad file descriptor’. The return code from the write
is -1.
Are you writing over the network?
If you have seen this problem, or have any ideas why this is occuring,
please let me know.
Regards,
Becki
Mario Charest <mcharest@void_zinformatic.com> wrote:
“Becki Drury” <> bdrury@softwareremodeling.com> > wrote in message
news:> 3A5B3FA5.FB548308@softwareremodeling.com> …
We are getting file write errors where the perror is ‘bad file
descriptor’. The return code from the write is -1.
When we printf the file descriptor before and after the write, it
appears to be ok.
We have created 2 tasks that use the same Base class.
Does tasks == threads ? If so file descriptor cannot be shared
across threads.
I was going to ask the same question. We don’t use the term “task”
under QNX4 to describe anything. So, when you use the term “task”,
what QNX4 construct do you mean?
– under QNX2 we had something called tasks, they were seperate
loaded & run programs, and are called processes under QNX4
– some other real-time OSes (eg Psos) have (had) something called
a “task” which has no direct equivalent under QNX4
– QNX4 has a (sort-of) thread model, but fds aren’t always shareable
between threads. The pthread library from /usr/free (qdn?) gives
better thread support.
-David
QNX Training Services
dagibbs@qnx.com
Chris Milette <cmilette@softwareremodeling.com> wrote:
David Gibbs wrote:
If I may since I work with Becki, task = process.
The point is, we’re not trying to share file descriptors between processes,
but two different processes have the same file descriptor. Then, sometime
during a write operation, in one process, the return value from the write =
-1,
and perror outputs “bad file descriptor”. However, when we check the
file descriptor, the value is the same as when the file was opened.
Hm… if you do a “sin fd”, or probably better for less output a
“sin -Pproblem_process fd” both after the creation of the fd, but
before you have problems and after you have the problems, what is
shown for this fd?
Does this fd point accross the network?
-David
QNX Training Services
dagibbs@qnx.com
David Gibbs wrote:
Mario Charest <mcharest@void_zinformatic.com> wrote:
“Becki Drury” <> bdrury@softwareremodeling.com> > wrote in message
news:> 3A5B3FA5.FB548308@softwareremodeling.com> …
We are getting file write errors where the perror is ‘bad file
descriptor’. The return code from the write is -1.
When we printf the file descriptor before and after the write, it
appears to be ok.
We have created 2 tasks that use the same Base class.
Does tasks == threads ? If so file descriptor cannot be shared
across threads.
I was going to ask the same question. We don’t use the term “task”
under QNX4 to describe anything. So, when you use the term “task”,
what QNX4 construct do you mean?
– under QNX2 we had something called tasks, they were seperate
loaded & run programs, and are called processes under QNX4
– some other real-time OSes (eg Psos) have (had) something called
a “task” which has no direct equivalent under QNX4
– QNX4 has a (sort-of) thread model, but fds aren’t always shareable
between threads. The pthread library from /usr/free (qdn?) gives
better thread support.
If I may since I work with Becki, task = process.
The point is, we’re not trying to share file descriptors between processes,
but two different processes have the same file descriptor. Then, sometime
during a write operation, in one process, the return value from the write =
-1,
and perror outputs “bad file descriptor”. However, when we check the
file descriptor, the value is the same as when the file was opened.
I hope this helps.
Chris
Yes, we were running over the network.
We changed it so that we were not running over the network today, and have not
been able to reproduce the error yet. It was random.
Thanks for the idea.
Becki
David Gibbs wrote:
Chris Milette <> cmilette@softwareremodeling.com> > wrote:
David Gibbs wrote:
If I may since I work with Becki, task = process.
The point is, we’re not trying to share file descriptors between processes,
but two different processes have the same file descriptor. Then, sometime
during a write operation, in one process, the return value from the write =
-1,
and perror outputs “bad file descriptor”. However, when we check the
file descriptor, the value is the same as when the file was opened.
Hm… if you do a “sin fd”, or probably better for less output a
“sin -Pproblem_process fd” both after the creation of the fd, but
before you have problems and after you have the problems, what is
shown for this fd?
Does this fd point accross the network?
-David
QNX Training Services
dagibbs@qnx.com
Becki Drury <bdrury@softwareremodeling.com> wrote:
This is a multi-part message in MIME format.
--------------3E38692475DDF5D7FFC3DE79
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Yes, we were running over the network.
We changed it so that we were not running over the network today, and have not
been able to reproduce the error yet. It was random.
Take a look at your netinfo logs “netinfo” and “netinfo -l”. If you are
losing packets, then Net can think that you’ve lost connection to another
node, it will tear down the virtual circuit (vc) that provides the connection
and your fd that was attached to the remote Fsys (or other device) will now
be a “bad filedescriptor”.
-David
QNX Training Services
dagibbs@qnx.com