[chromium-dev] Re: Are we now using Visual Studio 2008?

[Tommi]

Did you try setting this environment variable?
GYP_MSVS_VERSION=2008

works fine for me. I've only got vs2008 installed and don't have to go
through the conversion wizard after sync.

On Mon, Sep 14, 2009 at 1:20 PM, Glen Murphy  wrote:

>
> > Ok I'll change it to opt in.
>
> FWIW, I have a fresh computer that *only* has VS2008 on it - until I
> found this thread, GYP was generating 2005 files, resulting in a
> conversion wizard when I attempted to open the solution. At this risk
> of yet more complexity, maybe the opt-in should only be for machines
> that have both?
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Knowing when a context menu is closed

[Tommi]

for Windows:http://msdn.microsoft.com/en-us/library/ms647599(VS.85).aspx
"The *WM_EXITMENULOOP* message informs an application's main window
procedure that a menu modal loop has been exited."

On Wed, Jul 22, 2009 at 2:13 PM, Albert J. Wong (王重傑)
wrote:

> I need to find a way to know when a context menu is "closed", either via a
> menu item selection, or via hitting escape, opening a new menu, unfocusing
> the window, etc.
> Ideally, there'd be some sort of "menu closed" function or event that is
> called when the menu stops being displayed.  On the gtk port, I see
> a RenderViewContextMenuGtk::StoppedShowing(), but nothing similar for
> Windows and Mac.
>
> Can anyone give me a pointer on how to do something like this for mac, and
> windows?
>
> Thanks,
> Albert
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: F5 Debug process

[Tommi]

thanks jeremy - applied that cl and got my cpus pegged even more ;)

On Fri, Jul 3, 2009 at 2:10 PM, Jeremy Orlow  wrote:

> Actually, there are a couple spots to edit:
> http://codereview.chromium.org/155057  -- maybe more
>
> Is it time to make this default yet?  It speeds up the build considerably
> and almost everyone uses it now.  It does make things a bit less
> deterministic, but you can always clobber build if something gets into a bad
> state.  And it's _much_ faster.
>
> J
>
>
> On Fri, Jul 3, 2009 at 10:22 AM, Tommi  wrote:
>
>> Don't know if this is what most do but I ended up adding it to
>> build\common.gpyi (line 471 in my case)
>> ...
>>   'VCCLCompilerTool': {
>> *'AdditionalOptions': '/MP',*
>> 'MinimalRebuild': 'false',
>> 'ExceptionHandling': '0',
>> 'BufferSecurityCheck': 'true',
>> 'EnableFunctionLevelLinking': 'true',
>> 'RuntimeTypeInfo': 'false',
>> 'WarningLevel': '3',
>> 'WarnAsError': 'true',
>> 'DebugInformationFormat': '3',
>>   },
>> ...
>>
>> If that's not what everyone else is doing, please let me know.
>>
>> On Fri, Jul 3, 2009 at 1:11 PM, PhistucK  wrote:
>>
>>> Where exactly do I add "/MP" (using Visual Basic Professional 2005)? (I
>>> know extremely little about the whole environment..)
>>>
>>>
>>> Thank you.
>>>
>>> ☆PhistucK
>>>
>>>
>>>
>>> On Fri, Jul 3, 2009 at 20:08, Peter Kasting wrote:
>>>
>>>> On Fri, Jul 3, 2009 at 9:32 AM, Mohamed Mansour wrote:
>>>>
>>>>> It depends on the machine you have. CPU power. HD etc. ... If you have
>>>>> incremental build turned on /MP it will take less time to compile as well.
>>>>>
>>>>
>>>> Note: /MP is "multiprocess build", not "incremental build".
>>>>
>>>> PK
>>>>
>>>
>>>
>>>
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: F5 Debug process

[Tommi]

Don't know if this is what most do but I ended up adding it to
build\common.gpyi (line 471 in my case)
...
  'VCCLCompilerTool': {
*'AdditionalOptions': '/MP',*
'MinimalRebuild': 'false',
'ExceptionHandling': '0',
'BufferSecurityCheck': 'true',
'EnableFunctionLevelLinking': 'true',
'RuntimeTypeInfo': 'false',
'WarningLevel': '3',
'WarnAsError': 'true',
'DebugInformationFormat': '3',
  },
...

If that's not what everyone else is doing, please let me know.

On Fri, Jul 3, 2009 at 1:11 PM, PhistucK  wrote:

> Where exactly do I add "/MP" (using Visual Basic Professional 2005)?(I
> know extremely little about the whole environment..)
>
>
> Thank you.
>
> ☆PhistucK
>
>
>
> On Fri, Jul 3, 2009 at 20:08, Peter Kasting  wrote:
>
>> On Fri, Jul 3, 2009 at 9:32 AM, Mohamed Mansour  wrote:
>>
>>> It depends on the machine you have. CPU power. HD etc. ... If you have
>>> incremental build turned on /MP it will take less time to compile as well.
>>>
>>
>> Note: /MP is "multiprocess build", not "incremental build".
>>
>> PK
>>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: reminder: don't use CHECK()

[Tommi]

I agree with Evan.
Since we don't control the environment, hardware, other software, etc, etc,
that our product runs on, we have to be more careful with error checking
than if we were writing server software.
CHECK is an extreme measure - it's "gambling" with TerminateProcess/abort()
- but also it can be expensive in terms of code size and cpu cycles.

On Tue, May 26, 2009 at 9:22 PM, Aaron Boodman  wrote:

>
> I get different stories about this all the time from different people.
> It would be great to have them as part of the style guide so that I
> can refer to it.
>
> One that you didn't cover is the invariant case. I originally used
> DCHECKs, but it seems like if you're just going to crash on the next
> line anyway, a CHECK makes more sense.


I don't think it's that simple and I'd really not want to encourage devs to
use CHECK simply as a guard for code that doesn't have error checks.


>
>
> - a
>
> On Tue, May 26, 2009 at 5:01 PM, Evan Martin  wrote:
> >
> > In many places we have "shouldn't-happen" situations where a functon
> > might return NULL or false.
> > Coming from working on Google code you might be tempted to use
> > CHECK(foobar != NULL).
> >
> > But in client software, things that should never happen end up
> > happening all the time because of someone's strange computer setup or
> > cosmic rays.  Our pattern is:
> >
> > 1) If it is just "this is highly unlikely", attempt to recover from the
> problem.
> > 2) If it is "this shouldn't happen, and if it does a developer should
> > learn about it", use something like
> >  if (!keyboard_has_spacebar) {
> >NOTREACHED() << " this keyboard is crazy, maybe our detection code
> > is wrong?";
> >return false;  // attempt recovery anyway
> >  }
> > 3) If it really is something that's so bad that it's a security
> > problem if we continue, you should use CHECK().  But these should be
> > very rare.
> >
> > >
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: VS2008 via gyp

[Tommi]

awesome! :)  thanks brad

On Mon, May 11, 2009 at 5:51 PM, Bradley Nelson wrote:

> Hi All,
> I've just dropped in a change to gyp that will generate visual studio 2008
> style projects (really just messes with the version numbers),
> if vs2008 is detected locally.
> This behavior is disabled on the buildbots at the moment.
>
> If this gets in your way you can control it with the GYP_MSVS_VERSION
> environment variable.
> GYP_MSVS_VERSION=2005 (force vs2005)
> GYP_MSVS_VERSION=2008 (force vs2008)
> GYP_MSVS_VERSION=auto (auto-detect latest, default)
>
> For everything other than chome.sln this will save you the trouble of the
> import step.
> Once everything is in gyp, this should all be seamless.
>
> Please let me know if anyone runs into issues with this change.
>
> Sometime soon we'll add a buildbot with vs2008 building so things hopefully
> won't be too broken.
>
> -BradN
>
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Turned on tcmalloc

[Tommi]

ah, thanks.  I synced, tried to build and hit the same problem.  clobbering
now.

On Thu, Apr 23, 2009 at 11:53 AM, Sverrir Á. Berg wrote:

> BTW: You will need to rebuild tcmalloc (e.g. touch one of the .cc files)
> Sverrir
>
>
>
> On Thu, Apr 23, 2009 at 11:52 AM, Sverrir Á. Berg wrote:
>
>> Commited 17 hours and 20 minutes ago:
>> http://src.chromium.org/viewvc/chrome?view=rev&revision=14257
>>
>> Sverrir
>>
>>
>>
>> On Thu, Apr 23, 2009 at 11:24 AM, Tommi  wrote:
>>
>>> maybe we should get this checked in to keep VS2008 devs out there happy.
>>>
>>>
>>> On Wed, Apr 22, 2009 at 4:42 PM, Sverrir Á. Berg 
>>> wrote:
>>>
>>>> See: http://codereview.chromium.org/92037
>>>> Sverrir
>>>>
>>>>
>>>>
>>>> On Wed, Apr 22, 2009 at 4:29 PM, Tommi  wrote:
>>>>
>>>>> I'm still getting those errors.  Like Sverrir I'm using VS2008.  What's
>>>>> the magic required to get chrome.dll to link?
>>>>>
>>>>>
>>>>> On Wed, Apr 22, 2009 at 11:02 AM, Mike Belshe wrote:
>>>>>
>>>>>> It should work :-)
>>>>>> I'd check chrome/app/chrome_dll.vcproj for changes.
>>>>>>
>>>>>> The basic idea is:
>>>>>>* these functions are now provided by an alternate libcmt which is
>>>>>> in the tcmalloc directory.
>>>>>>* there is a build step as part of tcmalloc which creates this
>>>>>> library (prep_libc.sh)
>>>>>>* chrome.dll now ignores libcmt.lib and manually links its own
>>>>>> libcmt.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 22, 2009 at 7:25 AM, Sverrir Á. Berg <
>>>>>> sver...@chromium.org> wrote:
>>>>>>
>>>>>>> Even after doing the clobber & runhooks raindance I'm getting linker
>>>>>>> errors:
>>>>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _malloc
>>>>>>> already defined in libcmt.lib(malloc.obj)
>>>>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _free
>>>>>>> already defined in libcmt.lib(free.obj)
>>>>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _calloc
>>>>>>> already defined in libcmt.lib(calloc.obj)
>>>>>>> ... (16 functions total)
>>>>>>>
>>>>>>> (VS2008/external depot)
>>>>>>>
>>>>>>> Any suggestions on how to solve this?
>>>>>>> Sverrir
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 22, 2009 at 10:05 AM, Mike Belshe wrote:
>>>>>>>
>>>>>>>> I turned on tcmalloc last night as an experiment.  I left it on so
>>>>>>>> far.
>>>>>>>> The good news is the perf:
>>>>>>>> http://build.chromium.org/buildbot/perf/dashboard/overview.html
>>>>>>>>
>>>>>>>> The bad news is the reliability bot shows some crashes.  I believe
>>>>>>>> these are crashes not caused by tcmalloc but exposed by it.  We'll 
>>>>>>>> figure
>>>>>>>> out a plan to fix them today, or to revert tcmalloc again.
>>>>>>>>
>>>>>>>> Thanks for your patience while we sort this out!
>>>>>>>>
>>>>>>>> Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> >>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Turned on tcmalloc

[Tommi]

maybe we should get this checked in to keep VS2008 devs out there happy.

On Wed, Apr 22, 2009 at 4:42 PM, Sverrir Á. Berg wrote:

> See: http://codereview.chromium.org/92037
> Sverrir
>
>
>
> On Wed, Apr 22, 2009 at 4:29 PM, Tommi  wrote:
>
>> I'm still getting those errors.  Like Sverrir I'm using VS2008.  What's
>> the magic required to get chrome.dll to link?
>>
>>
>> On Wed, Apr 22, 2009 at 11:02 AM, Mike Belshe  wrote:
>>
>>> It should work :-)
>>> I'd check chrome/app/chrome_dll.vcproj for changes.
>>>
>>> The basic idea is:
>>>* these functions are now provided by an alternate libcmt which is in
>>> the tcmalloc directory.
>>>* there is a build step as part of tcmalloc which creates this library
>>> (prep_libc.sh)
>>>* chrome.dll now ignores libcmt.lib and manually links its own libcmt.
>>>
>>> Mike
>>>
>>>
>>>
>>> On Wed, Apr 22, 2009 at 7:25 AM, Sverrir Á. Berg 
>>> wrote:
>>>
>>>> Even after doing the clobber & runhooks raindance I'm getting linker
>>>> errors:
>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _malloc
>>>> already defined in libcmt.lib(malloc.obj)
>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _free already
>>>> defined in libcmt.lib(free.obj)
>>>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _calloc
>>>> already defined in libcmt.lib(calloc.obj)
>>>> ... (16 functions total)
>>>>
>>>> (VS2008/external depot)
>>>>
>>>> Any suggestions on how to solve this?
>>>> Sverrir
>>>>
>>>>
>>>> On Wed, Apr 22, 2009 at 10:05 AM, Mike Belshe wrote:
>>>>
>>>>> I turned on tcmalloc last night as an experiment.  I left it on so far.
>>>>> The good news is the perf:
>>>>> http://build.chromium.org/buildbot/perf/dashboard/overview.html
>>>>>
>>>>> The bad news is the reliability bot shows some crashes.  I believe
>>>>> these are crashes not caused by tcmalloc but exposed by it.  We'll figure
>>>>> out a plan to fix them today, or to revert tcmalloc again.
>>>>>
>>>>> Thanks for your patience while we sort this out!
>>>>>
>>>>> Mike
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> >>>
>>>
>>
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Turned on tcmalloc

[Tommi]

I'm still getting those errors.  Like Sverrir I'm using VS2008.  What's the
magic required to get chrome.dll to link?

On Wed, Apr 22, 2009 at 11:02 AM, Mike Belshe  wrote:

> It should work :-)
> I'd check chrome/app/chrome_dll.vcproj for changes.
>
> The basic idea is:
>* these functions are now provided by an alternate libcmt which is in
> the tcmalloc directory.
>* there is a build step as part of tcmalloc which creates this library
> (prep_libc.sh)
>* chrome.dll now ignores libcmt.lib and manually links its own libcmt.
>
> Mike
>
>
>
> On Wed, Apr 22, 2009 at 7:25 AM, Sverrir Á. Berg wrote:
>
>> Even after doing the clobber & runhooks raindance I'm getting linker
>> errors:
>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _malloc already
>> defined in libcmt.lib(malloc.obj)
>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _free already
>> defined in libcmt.lib(free.obj)
>> 143>tcmalloc.lib(override_functions.obj) : error LNK2005: _calloc already
>> defined in libcmt.lib(calloc.obj)
>> ... (16 functions total)
>>
>> (VS2008/external depot)
>>
>> Any suggestions on how to solve this?
>> Sverrir
>>
>>
>> On Wed, Apr 22, 2009 at 10:05 AM, Mike Belshe  wrote:
>>
>>> I turned on tcmalloc last night as an experiment.  I left it on so far.
>>> The good news is the perf:
>>> http://build.chromium.org/buildbot/perf/dashboard/overview.html
>>>
>>> The bad news is the reliability bot shows some crashes.  I believe these
>>> are crashes not caused by tcmalloc but exposed by it.  We'll figure out a
>>> plan to fix them today, or to revert tcmalloc again.
>>>
>>> Thanks for your patience while we sort this out!
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: purecall exceptions and the manbearpig

[Tommi]

hehe, understood! :)

On Sat, Apr 4, 2009 at 12:43 PM, Nicolas Sylvain wrote:

>
>
> On Fri, Apr 3, 2009 at 7:19 PM, Tommi  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 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 
>>> 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  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  wrote:
>>>>
>>>>> Based on what I saw in the bug, it looks like an exception happening
>&

[chromium-dev] Re: purecall exceptions and the manbearpig

[Tommi]

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.

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 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 
> 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  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  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 
>>> 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 
>>> wrote:
>>> >>
>>> >> You could, however, corrupt the vtable pointer (not the vtable).  Say
>>> >> somehow 32 was added to it, now the table is misaligned, and y

[chromium-dev] Re: purecall exceptions and the manbearpig

[Tommi]

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  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 
> 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 
> 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  wrote:
> >> > On Thu, Apr 2, 2009 at 7:09 PM, cpu  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Apr 2, 3:53 pm, Nicolas Sylvain  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  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 _purecal

[chromium-dev] Re: purecall exceptions and the manbearpig

[Tommi]

On Thu, Apr 2, 2009 at 7:09 PM, cpu  wrote:

>
>
>
> On Apr 2, 3:53 pm, Nicolas Sylvain  wrote:
> > Another simple(r) example :
> 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  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 cra

[chromium-dev] Re: Quick question about struct initialization

[Tommi]

The {0} initialization zeros out the entire struct, not just the first
member of the struct.
These two are functionally equivalent:

char foo[10] = {0};
MyStruct bar = {0};

and

char foo[10];
memset(foo, 0, sizeof(foo));
MyStruct bar;
memset(&bar, 0, sizeof(bar));

On Sun, Mar 22, 2009 at 2:36 PM, Paul Topping  wrote:

>
> Your {0} initialization only inits the first element of the struct (or the
> whole struct if it consists of a single element), whereas memset inits the
> struct completely to 0 regardless of its size or internal structure.
>
> On the other hand, zeroing an entire struct with memset is dangerous unless
> it is guaranteed to be POD. If someone later changes the struct such that it
> is no longer POD, memset will still compile and run but it may overwrite
> some struct member constructor's work.
>
> Paul
>
> > -Original Message-
> > From: chromium-dev@googlegroups.com [mailto:chromium-
> > d...@googlegroups.com] On Behalf Of Book'em Dano
> > Sent: Sunday, March 22, 2009 11:30 AM
> > To: Chromium-dev
> > Subject: [chromium-dev] Re: Quick question about struct initialization
> >
> >
> > Sorry if I wasn't clear enough, but that's actually what my question
> > is.
> >
> > What's the need/point of calling memset if initialization via " = {0};
> > " works just as well. Are you saying that it doesn't? Or are you
> > saying that you're not quite sure, and to be on the safe side, do
> > both. I'd like to avoid doing work (even if only 1 a liner) that isn't
> > needed. i'd like to put this to rest once and for all, so if anyone
> > knows, could please help me out here.
> >
> > Cheers,
> > Danny
> >
> > On Mar 22, 5:23 am, Smita  wrote:
> > > It works fine with gcc.
> > > However, you might want to initialize the entire array to 0 using a
> > > memset.
> > >
> > > Smita
> > >
> > > On Mar 21, 10:23 pm, "Book'em Dano"  wrote:
> > >
> > > > Can someone please confirm whether it's safe to initialize a POD
> > > > struct using:
> > >
> > > > MyStruct blat = {0};
> > >
> > > > with gcc on Linux/Mac? I know this works fine with the VC compiler,
> > > > but I dont have gcc handy.
> > >
> > > > Thanks,
> > > > D
> >
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Problem with 'gcl' use.

[Tommi]

Hey DeArto20,

Try running gcl from the src directory.  For me that's C:\chromium\src.

On Thu, Jan 1, 2009 at 2:00 PM, DeArto20  wrote:

>
> Hi.
>
>
> I have a problem during 'request review'.
>
> Specifically, when i execute 'gcl change XXX' in the command window, I
> get the following result.
>
> "gcl run outside of repository"
>
>
> How can i solve this problem. Plz let me know what should i do.
>
> Have a good day!
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---