so, how's about that detailed explanation?

[Phil Edwards <pedwards at disaster dot jaj dot com>]

I'm debugging the core dumps that occur on *every* executable
linked against a shared v3 under solaris.  Initially reported in
http://sources.redhat.com/ml/libstdc++/2000-10/msg00206.html, but at the
time I thought it was sporadic.

(I'll also be checking in a boatload of changes to mkcheck.in when I'm done,
for more precise control and reporting.) In the meantime...

In basic_file.h, accompanying __basic_file_base, is a comment:

  // Ulrich is going to make some detailed comment here, explaining
  // all this unpleasantness, providing detailed performance analysis
  // as to why we have to do all this lame vtable hacking instead of a
  // sane, function-based approach. This verbage will provide a clear
  // and detailed description of the whole object-layout,
  // vtable-swapping, sordid history of this hack.

I think we need that comment.  :-)

What seems to be happening is that _IO_new_file_overflow is being called
with a valid _IO_FILE*/'this' pointer pointing to a structure full of zeros,
and a 'ch' argument of 3.  (See for example the backtrace I posted in the
mail message above.)

Now, get this:  the test case is 17/header_ciso646, which does no output
at all.  The operation above occurs when cout is being cleaned up.
(Why would it need to overflow the buffer when nothing got written?)

The funky vtable isn't causing this -- hmm, but _IO_file_overflow is in
the next slot over from the __basic_file dtor, off by one? -- but trying
to trace through these calls when they magically hop from a class's base
class's base class into the guts of libio is difficult when I don't know
what's supposed to happen.

And that's the *short* version of the story.


Have a good weekend, all,
Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.