|
Miguel Simon
10/05/2008 2:57 PM
post14492
|
Hi...
system:
# uname -a
QNX sim0 6.3.2 2006/03/16-14:19:42EST x86pc x86
what: io_read(...)
at the io_read() handle. the data to write to the client looks like:
{55, 583, 3071, 561, 2436, 3342, 2048, 2450, 2048, 2048 }
when the client gets the data, this data looks like:
{55, 583, 3071, 561, 59384, 45106, 49512, 45109, 2048, 2048}
source of problem:
when using io_read(...), the buffer where the data is stored needs to be global. I was using a buffer defined in a
namespace, but this was apparantly not a good thing. When I moved this buffer to be a global entity, then all worked
well.
question:
is this behavior documented, namely that a buffer that contains data to be used by io_read() to send to the client
read() needs to be global and not a mamber of a namespace?
I did not find this documented any where. Examples show that this has be the case, but I did not find that this MUST be
the case.
cost of labor: three full days (including Saturday) to find this silly (apparently undocumented) issue. Or else I
missed the documentation where this is explained.
Thanks...
Regards.
Miguel.
|
|
|
|
|
|
Sean Boudreau(deleted)
10/05/2008 4:44 PM
post14495
|
On Sun, Oct 05, 2008 at 02:57:58PM -0400, Miguel Simon wrote:
> Hi...
>
> system:
>
> # uname -a
> QNX sim0 6.3.2 2006/03/16-14:19:42EST x86pc x86
>
>
> what: io_read(...)
>
> at the io_read() handle. the data to write to the client looks like:
>
> {55, 583, 3071, 561, 2436, 3342, 2048, 2450, 2048, 2048 }
>
> when the client gets the data, this data looks like:
>
> {55, 583, 3071, 561, 59384, 45106, 49512, 45109, 2048, 2048}
>
>
> source of problem:
>
> when using io_read(...), the buffer where the data is stored needs to be global. I was using a buffer defined in a
namespace, but this was apparantly not a good thing. When I moved this buffer to be a global entity, then all worked
well.
>
> question:
>
> is this behavior documented, namely that a buffer that contains data to be used by io_read() to send to the client
read() needs to be global and not a mamber of a namespace?
>
> I did not find this documented any where. Examples show that this has be the case, but I did not find that this MUST
be the case.
>
>
> cost of labor: three full days (including Saturday) to find this silly (apparently undocumented) issue. Or else I
missed the documentation where this is explained.
The buffer from which a server replies to an io-read message
doesn't have to be a global. In fact it's usually not, especially
with a multi threaded server. I suspect you've changed some
memory layout which just happened to work around the root issue.
Regards,
-seanb
|
|
|
|
|
|
Miguel Simon
10/05/2008 11:33 PM
post14497
|
Hi...
Thanks.
This being the case, I suppose that I'll work some more to find the root of the issue. All the tests that I have shown
show that the data gets corrupted from the io_read() to the client's read(). This with one single debug step. As a
matter of fact, I have created a fake array, populate it, and I still see the problem. In any case, thank you for your
help.
Regards...
Miguel.
|
|
|
|
|
|
Xiaodan Tang(deleted)
10/06/2008 8:51 AM
post14507
|
Ultimately, it boils down to the kernel call "MsgReply(rcvid, retval,
bufptr, buflen)";
My guess is, at the end of your io_read(), you are returning the data by
"return _RESMGR_PTR(...);". If you look at that _RESMGR_PTR macro, you
can see it just put the buffer pointer into ctp; Once returned, the
framework will then do the MsgReply() for you with the pointers in ctp.
This of cause means your buffer can not be local to io_read(), (can't on
io_read()'s stack) as once returned, these data are invalid.
If you really have data on stack you want to send back, you can do the
MsgReply() yourself.
MsgReply(ctp->rcvid, nbytes, bufptr_on_stack, buflen);
The "nbytes" will be the return value of client's read() function. And
at the end of the function:
return _RESMGR_NOREPLY;
To tell the framework NOT TO do the MsgReply() for you.
Does this all make sense now?
Thanks,
-xtang
-----Original Message-----
From: Miguel Simon [mailto:community-noreply@qnx.com]
Sent: October 5, 2008 11:34 PM
To: ostech-core_os
Subject: Re: io_read behavior
Hi...
Thanks.
This being the case, I suppose that I'll work some more to find the root
of the issue. All the tests that I have shown show that the data gets
corrupted from the io_read() to the client's read(). This with one
single debug step. As a matter of fact, I have created a fake array,
populate it, and I still see the problem. In any case, thank you for
your help.
Regards...
Miguel.
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post14497
|
|
|
|
|
|
