Re: PATCH: for Serious v3 shared library bug

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20010102203930.A2493@disaster.jaj.com>,
Phil Edwards <pedwards@disaster.jaj.com> writes:

> A few weeks ago I started investigating that exact test; see my message on
> (I think) the 22nd about sync_with_stdio().

OK, that would be: http://gcc.gnu.org/ml/libstdc++/2000-12/msg00264.html

Did the eggnog-induced vision provide much insight? ;-)

> That non-standard __sys_open is proving to be both our friend and
> enemy in the implemented-using-stdio case.  And tracing things that
> happen before main isn't working for me in gdb, so there's too much
> guesswork involved.

Yes, until you have a gdb that gonks the new mangling (V3 G++ ABI)
style, it can be somewhat difficult (in that you have to mangle by
hand before feeding to gdb).  I don't have one built yet.

OK, I understand your point about this being an area with a bug
waiting to happen.  This is just due to the complexity of trying to
link stdio to libstdc++.  I think I now understand what is happening
and what is suppose to happen (at least as much as I can from
consulting only TC++PL-SE).  I have a patch for sync_with_stdio() that
fixes the errant creation of new files.

> I had changed sync_with_stdio() to behave more like ios_base::Init::Init():
> save a pointer to the old filebuf, construct a new one using the non-std
> fd-passing ctor, destroy the old filebuf.  But the descriptors kept
> getting closed because (under solaris) the stdio implementation is used.
> Variations on this theme don't help.

You are correct.  If fdopen(__fd, ...) is ever called with __fd = 0,
1, 2 and that result is later fclose()'d (which would happen whenever
you destroy the filebuf), then the handle to a standard descriptor
will be lost forever.  Obviously, this is not good and I suspect was
happening in all your variations.

> Now I have a new Linux system, and not a single C++ program will run.  Ha.
> So I haven't gotten back to the Solaris system yet.

Sorry, can't help you there.

> This brings two questions to my mind.  Forgive me if I'm being stupid;
> I haven't gotten enough sleep.

> 1)  How does ios_base::Init::Init() get away with calling __old->~streambuf()
> to dispose of buffers, where doing the same thing during sync_with_stdio()
> closes the descriptors?

There is a difference between a streambuf and a filebuf.  Just by
tracing the source, it is clear to see that ~filebuf() closes the
descriptor.  A streambuf holds no descriptor, thus there is nothing to
close.

> 2)  If we treat file descriptors 0/1/2 specially -- as we are in
> ios_base::Init::Init() and sync_with_stdio() -- then are we /really/
> using a separate buffer after de-synch'ing from stdio?

I believe that you will in my forthcoming patch.  In the case where
sync_with_stdio(false) is called, I intend to use dup()'d descriptors.

Regards,
Loren