Race in rpc__cn_network_receiver()?
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Thu Apr 20 03:33:29 CDT 2006
On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote:
luke, you are a star: thank you for helping out with this.
just for people's information (in case it's not been mentioned here - i
must admit i forgot to notify opendce at opengroup.org!)
about 6-8 months ago i did a coding-spree on freedce, with a view to
achieving two, maybe three, major things:
1) porting to win32 (if you use pthreads-win32)
2) using posix final draft (7?) threads not posix draft 4.
3) proving to the people on wine and reactos that they have
a hell of a lot of work to do (measured in man-decades)
by not using the open group's DCE/RPC reference
here's the gotchas that i encountered, and had to give up:
- udp worked, but tcp did not
- reactos had some problems at the time with the code behind
ipconfig.exe (NetTransportEnum i think it was)
- pthreads-win32 was too strictly posix compliant (!)
and there is a cancellation exception or something which
makes it fail in the dcethreads exception library tests,
where linux does not fail (!)
maybe this is related to what lukeh is talking about.
anyway, the upshot is that freedce/latest-cvs also doesn't work
on TCP, and thank you so much people for helping track down why.
it's only been ten years so far: hopefully some time within the next
decade, freedce will be used for some real MSRPC-related free
> >In rpc__cn_network_receiver(), rpc__socket_close() is called without an
> >exception handler in place. According to IEEE Std 1003.1 (2004), close()
> >is a cancellation point, see:
> >Given this, a receiver thread could receive a cancel whilst closing the
> >socket, which will cause to entire program to abort. (We have seen this
> >occur when the RPC server is under load.)
> >A suggested fix is to move the call to rpc__socket_close() inside the
> >TRY/CATCH_ALL block that removes any pending cancels.
> It seems like the real fix is to disable cancellation within
> rpc__socket_close(), because in other places the OSF code appears to
> assume that this is not a cancellation point.
> Ditto for open(), socket(), etc (but not I/O routines that may block).
> I should note that the Linux dcethreads library does actually disable
> cancellation for these calls, however in our own DCE thread library
> we opted not to override any system calls to avoid changing semantics
> when used by non-DCE code.
> -- Luke
lkcl.net - mad free software computer person, visionary and poet.
More information about the wine-devel