Re: bug in pipe() and pipe2()

[Ryan Johnson <ryan dot johnson at cs dot utoronto dot ca>]

On 30/06/2011 5:38 AM, Corinna Vinschen wrote:
> On Jun 29 15:30, Eric Blake wrote:
> > I was testing the behavior when pipe() fails, in order to propose an
> > update to POSIX wording: http://austingroupbugs.net/view.php?id=467
> >
> > However, cygwin's pipe implementation dumps core when it runs out of
> > fds, [...]
> > Expected behavior is EMFILE and fd unchanged, after however many
> > iterations it takes to reach the ulimit on max fd.
> The problem is that Cygwin uses a placement new operator to allocate
> new fhandlers.  This type of new operator calls the constructor even
> if the placement pointer is NULL.  This in turn crashes in a rather
> obvious way.
>
> Since we need the placement new for fhandlers to make sure they are
> allocated on the cygheap, and since there is no such operator which
> only calls the constructor, I only see a very ugly workaround for this
> problem.
>
> I checked it in, together with two more fixes to avoid a crash.
> If somebody has a better solution, feel free to mention it.
If you don't mind using a couple of gcc extensions (we are a gcc-only 
shop, right?):

#define cnew(name, ...) ({                                              \
            void* ptr = (void*) ccalloc (HEAP_FHANDLER, 1, sizeof 
(name)); \
            ptr? new(ptr) name(__VA_ARGS__) : NULL;                     \
        })

The macro's usage would change to look like a normal function call:

fhandler_base *fh = cnew(fhandler_nodevice);

You just need to check fh != NULL afterward. If the ctor for 
fhandler_nodevice took an argument 'x' it would follow as additional 
args to the cnew macro, rather than as an additional set of parens:

fhandler_base *fh = cnew(fhandler_nodevice, x);

Regards,
Ryan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple