On Fri, Apr 3, 2009 at 7:19 PM, Tommi <to...@chromium.org> wrote:
> Yes, that's one way of running into purecall. but, just in case my email
> is being misunderstood, now with italics! :)
>
> "purecall is not called *when* an exception occurs. purecall actually
> *throws
> the exception - or exits the program"*
>
> purecall is called when attempting to call a virtual method for which there
> is no implementation. purecall is the default virtual method if you will.
>
Yes, that's the low level description of purecall, and no one is debating
that.
But it is also misleading, because, from a high level perspective, when you
look at my code, you see that the developer actually did implement the
virtual method explicitly, so, still from a high level perspective, it can
also happen for a virtual method that does have an implementation if the
object has been deleted prior to the call. [All that because when the
derived object is deleted, one of the thing it does is to revert its vtable
to the base class vtable. That part is not obvious/known to the high level
developer]
It's not because you implement all your virtual functions correctly that
your objects wont purecall. But I'm sure you know that, I just wanted to
make sure I'm not misunderstood either ;)
Nicolas
> When you call _set_purecall_handler, you're giving _purecall a pointer to
> your function that purecall will delegate to. There's not an exception that
> triggers this. Calling purecall is just a regular function call.
>
> Here's CRT's implementation of __purecall:
>
> void __cdecl _purecall() {
> _purecall_handler purecall = (_purecall_handler)
> _decode_pointer(__pPurecall);
> if(purecall != NULL) {
> purecall();
> /* shouldn't return, but if it does, we drop back to
> default behaviour
> */
> }
>
> _NMSG_WRITE(_RT_PUREVIRT);
> /* do not write the abort message */
> _set_abort_behavior(0, _WRITE_ABORT_MSG);
> abort();
> }
>
> and here's the implementation of _set_purecall_handler:
>
> _purecall_handler _set_purecall_handler(_purecall_handler pNew) {
> _purecall_handler pOld = NULL;
> pOld = (_purecall_handler) _decode_pointer(__pPurecall);
> __pPurecall = (_purecall_handler) _encode_pointer(pNew);
> return pOld;
> }
>
>
> On Fri, Apr 3, 2009 at 8:42 PM, Nicolas Sylvain <nsylv...@chromium.org>wrote:
>
>> The code below shows that it's possible to throw a purecall exception by
>> calling a function from a delete object.
>>
>> I suspect this is what is happening in our code.
>>
>> Nicolas
>>
>>
>> class Derived;
>> class Base {
>> public:
>> Base(Derived *derived): m_pDerived(derived) {};
>> ~Base() {}; // Needed, dont know why.
>> virtual void function(void) = 0;
>> void bleh();
>> Derived * m_pDerived;
>> };
>>
>> class Derived : public Base {
>> public:
>> Derived() : Base(this) {}; // C4355
>> virtual void function(void) {};
>> };
>>
>> void Base::bleh() {
>> m_pDerived -> function();
>> }
>>
>> void purecall(void) {
>> __debugbreak();
>> }
>>
>> #include <windows.h>
>> int _tmain(int argc, _TCHAR* argv[]) {
>> _set_purecall_handler(purecall);
>> Base* base = NULL;
>> {
>> Derived myDerived;
>> myDerived.function();
>> base = &myDerived;
>> }
>> base->bleh();
>> }
>>
>> On Fri, Apr 3, 2009 at 2:17 PM, Tommi <to...@chromium.org> wrote:
>>
>>> purecall isn't called when an exception occurs. purecall actually throws
>>> the exception - or exits the program (by default the crt throws up a dialog
>>> and then abort()s). in addition to cpu's email, raymond chen's article is a
>>> good (and short) read :)
>>> http://blogs.msdn.com/oldnewthing/archive/2004/04/28/122037.aspx
>>>
>>> On Fri, Apr 3, 2009 at 3:15 PM, Huan Ren <hu...@google.com> wrote:
>>>
>>>> Based on what I saw in the bug, it looks like an exception happening
>>>> during CALL instruction may lead to PureCall().
>>>>
>>>> For example, an object obj has been freed and later on someone calls
>>>> obj->func(). Then the assembly code looks like this:
>>>>
>>>> // ecx: pointer to obj which is in memory
>>>> // [ecx]: supposed to be pointer to vtable, it has invalid value since
>>>> obj is freed
>>>> // edx: now has pointer to vtable, which is invalid
>>>> mov edx,dword ptr [ecx]
>>>>
>>>> // deref the vtable and make the call
>>>> call dword ptr [edx+4]
>>>>
>>>> When a (hardware) exception happens during the call instruction, the
>>>> control will be eventually transfered to the routine handling this
>>>> type of exception which I *think* is PureCall().
>>>>
>>>> Huan
>>>>
>>>> On Fri, Apr 3, 2009 at 11:26 AM, Ricardo Vargas <rvar...@chromium.org>
>>>> wrote:
>>>> > I certainly don't want to imply that it is the case with this
>>>> particular
>>>> > bug, but I have seen crashes when the cause of the problem is using an
>>>> > object that was previously deleted (and only end up with this
>>>> exception when
>>>> > all the planets are properly aligned). I guess that it depends on the
>>>> actual
>>>> > class hierarchy of the objects in question, but I'd think that
>>>> "simple"
>>>> > examples end up on a lot of crashes right after the cl that exposes
>>>> the
>>>> > problem.
>>>> >
>>>> > On Fri, Apr 3, 2009 at 12:52 AM, Dean McNamee <de...@chromium.org>
>>>> wrote:
>>>> >>
>>>> >> You could, however, corrupt the vtable pointer (not the vtable). Say
>>>> >> somehow 32 was added to it, now the table is misaligned, and you
>>>> might
>>>> >> get a purecall, etc. Not sure that's likely at all though.
>>>> >>
>>>> >> Since the vtable pointer is the first field, it seems ripe for
>>>> >> problems w/ use after free, etc. I kinda doubt that's what's
>>>> >> happening here though. Anyone who is working on one of these can bug
>>>> >> me and I'll look at the crash dump.
>>>> >>
>>>> >> On Fri, Apr 3, 2009 at 7:24 AM, Tommi <to...@chromium.org> wrote:
>>>> >> > On Thu, Apr 2, 2009 at 7:09 PM, cpu <c...@chromium.org> wrote:
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> On Apr 2, 3:53 pm, Nicolas Sylvain <nsylv...@chromium.org> wrote:
>>>> >> >> > Another simple(r) example
>>>> >> >> > :http://msdn.microsoft.com/en-us/library/t296ys27(VS.80).aspx
>>>> >> >> >
>>>> >> >> > <http://msdn.microsoft.com/en-us/library/t296ys27(VS.80).aspx>But,
>>>> as
>>>> >> >> > discussed in bug 8544, we've see many purecall crashes that
>>>> happens
>>>> >> >> > and
>>>> >> >> > we
>>>> >> >> > don't
>>>> >> >> > think it's related to virtual functions. The only thing I can
>>>> think
>>>> >> >> > of
>>>> >> >> > is
>>>> >> >> > that the vtable is corrupted. (overwritten or freed)
>>>> >> >> >
>>>> >> >> > Does it not make sense?
>>>> >> >>
>>>> >> >> I don't think you can overwrite a vtables because they should be
>>>> in
>>>> >> >> the code section of the executable (the pages marked as
>>>> read-execute),
>>>> >> >> they are known at compile time and it would not make sense to
>>>> >> >> construct them on the fly.
>>>> >> >>
>>>> >> >> But if you know of a case then that would be very interesting.
>>>> >> >
>>>> >> >
>>>> >> > yes they should be protected with read/execute and besides, you'd
>>>> have
>>>> >> > to
>>>> >> > overwrite entries in the vtable with a pointer to __purecall for
>>>> that to
>>>> >> > happen
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >>
>>>> >> >> >
>>>> >> >> > Nicolas
>>>> >> >> >
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > On Thu, Apr 2, 2009 at 1:54 PM, cpu <c...@chromium.org> wrote:
>>>> >> >> >
>>>> >> >> > > After reading some speculation in bugs such as
>>>> >> >> > >http://code.google.com/p/chromium/issues/detail?id=8544I felt
>>>> >> >> > > compelled to dispel some myths and misunderstandings about the
>>>> >> >> > > origin
>>>> >> >> > > and meaning of the mythical _purecall_ exception. My hope is
>>>> that
>>>> >> >> > > then
>>>> >> >> > > you can spot the problems in our source code and fix them.
>>>> Sorry
>>>> >> >> > > for
>>>> >> >> > > the long post.
>>>> >> >> >
>>>> >> >> > > So first of all, what do you see when you get this error? if
>>>> you
>>>> >> >> > > are
>>>> >> >> > > in a debug build and you are not eating the exceptions via
>>>> some
>>>> >> >> > > custom
>>>> >> >> > > handler you see this dialog:
>>>> >> >> >
>>>> >> >> > > ---------------------------
>>>> >> >> > > Debug Error!
>>>> >> >> > > R6025
>>>> >> >> > > - pure virtual function call
>>>> >> >> > > (Press Retry to debug the application)
>>>> >> >> > > ---------------------------
>>>> >> >> > > Abort Retry Ignore
>>>> >> >> > > ---------------------------
>>>> >> >> >
>>>> >> >> > > For chrome/chromium we install a special handler, which forces
>>>> a
>>>> >> >> > > crash
>>>> >> >> > > dump in which case you'll see in in the debugger analysis
>>>> something
>>>> >> >> > > like this:
>>>> >> >> >
>>>> >> >> > > [chrome_dll_main.cc:100] - `anonymous namespace'::PureCall()
>>>> >> >> > > [purevirt.c:47] - _purecall
>>>> >> >> >
>>>> >> >> > > Before going into too much detail, let me show you a small
>>>> program
>>>> >> >> > > that causes this exception:
>>>> >> >> >
>>>> >> >> > > =================================
>>>> >> >> > > class Base {
>>>> >> >> > > public:
>>>> >> >> > > virtual ~Base() {
>>>> >> >> > > ThreeFn();
>>>> >> >> > > }
>>>> >> >> >
>>>> >> >> > > virtual void OneFn() = 0;
>>>> >> >> > > virtual void TwoFn() = 0;
>>>> >> >> >
>>>> >> >> > > void ThreeFn() {
>>>> >> >> > > OneFn();
>>>> >> >> > > TwoFn();
>>>> >> >> > > }
>>>> >> >> > > };
>>>> >> >> >
>>>> >> >> > > class Concrete : public Base {
>>>> >> >> > > public:
>>>> >> >> > > Concrete() : state_(0) {
>>>> >> >> > > }
>>>> >> >> >
>>>> >> >> > > virtual void OneFn() {
>>>> >> >> > > state_ += 1;
>>>> >> >> > > }
>>>> >> >> > > virtual void TwoFn() {
>>>> >> >> > > state_ += 2;
>>>> >> >> > > }
>>>> >> >> > > private:
>>>> >> >> > > int state_;
>>>> >> >> > > };
>>>> >> >> >
>>>> >> >> > > int _tmain(int argc, _TCHAR* argv[]) {
>>>> >> >> >
>>>> >> >> > > Concrete* obj = new Concrete();
>>>> >> >> > > obj->OneFn();
>>>> >> >> > > obj->TwoFn();
>>>> >> >> > > obj->ThreeFn();
>>>> >> >> >
>>>> >> >> > > delete obj;
>>>> >> >> >
>>>> >> >> > > return 0;
>>>> >> >> > > }
>>>> >> >> > > =================================
>>>> >> >> >
>>>> >> >> > > Can you spot the problem? do you know at which line it
>>>> crashes, do
>>>> >> >> > > you
>>>> >> >> > > know why? if so I have wasted your time, apologies. If you are
>>>> >> >> > > unsure
>>>> >> >> > > then read on.
>>>> >> >> >
>>>> >> >> > > This program crashes when trying to call OneFn() with a
>>>> purecall
>>>> >> >> > > exception on debug build. On release build it exits with no
>>>> error,
>>>> >> >> > > but
>>>> >> >> > > your mileage might vary depending on what optimizations are
>>>> active.
>>>> >> >> >
>>>> >> >> > > The call stack for the crash is:
>>>> >> >> >
>>>> >> >> > > msvcr80d.dll!__purecall() + 0x25
>>>> >> >> > > <------
>>>> >> >> > > shows the
>>>> >> >> > > dialog (debug only)
>>>> >> >> > > app.exe!Base::ThreeFn() Line 16 + 0xfc <-----
>>>> error
>>>> >> >> > > here
>>>> >> >> > > app.exe!Base::~Base() Line 10 C++
>>>> >> >> > > app.exe!Concrete::~Concrete() + 0x2b
>>>> >> >> > > app.exe!Concrete::`scalar deleting destructor'() +
>>>> 0x2b
>>>> >> >> > > <-----
>>>> >> >> > > delete obj
>>>> >> >> >
>>>> >> >> > > So as you have guessed it has to do with calling virtual
>>>> functions
>>>> >> >> > > from a destructor.
>>>> >> >> >
>>>> >> >> > > What happens is that during construction an object evolves
>>>> from the
>>>> >> >> > > earliest base class to the actual type and during destruction
>>>> the
>>>> >> >> > > object devolves (is that a word?) from the actual object to
>>>> the
>>>> >> >> > > earliest base class; when we reach ~Base() body the object is
>>>> no
>>>> >> >> > > longer of type Concrete but of type Base and thus the call
>>>> >> >> > > Base::OneFn
>>>> >> >> > > () is an error because that class does not in fact have any
>>>> >> >> > > implementation.
>>>> >> >> >
>>>> >> >> > > What the compiler does is create two vtables, the vtable of
>>>> >> >> > > Concrete
>>>> >> >> > > looks like this:
>>>> >> >> >
>>>> >> >> > > vtable 1:
>>>> >> >> > > [ 0 ] -> Concrete::OneFn()
>>>> >> >> > > [ 1 ] -> Concrete::TwoFn()
>>>> >> >> >
>>>> >> >> > > vtable 2:
>>>> >> >> > > [ 0 ]-> msvcr80d.dll!__purecall()
>>>> >> >> > > [ 1 ]-> msvcr80d.dll!__purecall()
>>>> >> >> >
>>>> >> >> > > The dtor of Concrete is the default dtor which does nothing
>>>> except
>>>> >> >> > > calling Base::~Base(), but the dtor of base does:
>>>> >> >> >
>>>> >> >> > > this->vtbl_ptr = vtable2
>>>> >> >> > > call ThreeFn()
>>>> >> >> >
>>>> >> >> > > Now, why doesn't the release build crash?
>>>> >> >> >
>>>> >> >> > > That's because the compiler does not bother with generating
>>>> the
>>>> >> >> > > second
>>>> >> >> > > vtable, after all is not going to be used and thus also
>>>> eliminates
>>>> >> >> > > the
>>>> >> >> > > related lines such as this->vtbl_ptr = vtable2. Therefore the
>>>> >> >> > > object
>>>> >> >> > > reaches the base dtor with the vtbl_ptr pointing to vtable1
>>>> which
>>>> >> >> > > makes the call ThreeFn() just work.
>>>> >> >> >
>>>> >> >> > > But that was just luck. If you ever modify the base class,
>>>> such as
>>>> >> >> > > introducing a new virtual function that is not pure, like
>>>> this:
>>>> >> >> >
>>>> >> >> > > class Base {
>>>> >> >> > > public:
>>>> >> >> > > virtual ~Base() {
>>>> >> >> > > ThreeFn();
>>>> >> >> > > }
>>>> >> >> >
>>>> >> >> > > virtual void OneFn() = 0;
>>>> >> >> > > virtual void TwoFn() = 0;
>>>> >> >> >
>>>> >> >> > > virtual void FourFn() { <--- new function, not pure
>>>> >> >> > > virtual
>>>> >> >> > > wprintf(L"aw snap");
>>>> >> >> > > }
>>>> >> >> >
>>>> >> >> > > void ThreeFn() {
>>>> >> >> > > OneFn();
>>>> >> >> > > TwoFn();
>>>> >> >> > > }
>>>> >> >> > > };
>>>> >> >> >
>>>> >> >> > > // Same program below.
>>>> >> >> > > // .......
>>>> >> >> > > // ========================
>>>> >> >> >
>>>> >> >> > > Then you are forcing the compiler to generate vtable 2, which
>>>> >> >> > > looks:
>>>> >> >> >
>>>> >> >> > > vtable 2:
>>>> >> >> > > [ 0 ]-> msvcr80d.dll!__purecall()
>>>> >> >> > > [ 1 ]-> msvcr80d.dll!__purecall()
>>>> >> >> > > [ 2 [-> Base::FourFn()
>>>> >> >> >
>>>> >> >> > > And now the purecall crash magically happens (on the same
>>>> spot) on
>>>> >> >> > > release builds, which is quite surprising since the trigger
>>>> was the
>>>> >> >> > > introduction of FourFn() which has _nothing_ to do with the
>>>> crash
>>>> >> >> > > or
>>>> >> >> > > the problem and is many commits after the introduction of the
>>>> >> >> > > problem.
>>>> >> >> >
>>>> >> >> > > So the moral of the story? beware of virtual calls on dtors
>>>> and
>>>> >> >> > > ctors.
>>>> >> >> > > Note that in practice this is quite tricky because of layers
>>>> of
>>>> >> >> > > indirection / complexity of the code base.
>>>> >> >> >
>>>> >> >> > > ... so and what about the manbearpig ? Ah, yes no longer a
>>>> myth:
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > >
>>>> >> >> > > > >
>>>> http://www.thinkgene.com/scientists-successfully-create-human-bear-pi.
>>>> ..
>>>> >> >> >
>>>> >> >> > > -cpu
>>>> >> >>
>>>> >> >
>>>> >> >
>>>> >> > >
>>>> >> >
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > >
>>>> >
>>>>
>>>
>>>
>>>
>>>
>>
>> >>
>>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
