Fix wierd string iteration problem in ParseDomainASCII under VS2010 debug builds

Fix wierd string iteration problem in ParseDomainASCII under VS2010 debug builds

This commit fixes a crash under MSVS 2010 Debug builds, where a string
iterator fails a compatibility check. Specifically its _Myproxy is NULL.
What that is and why that is exactly I do not know at this point, but I'd
guess it may be a VS2010 bug.

Creating a new string copy rather than using the existing one
seems to resolve the issue.

BUG=131599
TEST=

[szym, 2012-06-07 17:31:02]

lgtm

[cbentzel, 2012-06-07 17:38:46]

https://chromiumcodereview.appspot.com/10544054/diff/1/net/dns/dns_config_ser...
File net/dns/dns_config_service_win.cc (right):

https://chromiumcodereview.appspot.com/10544054/diff/1/net/dns/dns_config_ser...
net/dns/dns_config_service_win.cc:116: #if defined(OS_WIN) && !defined(NDEBUG)
Can this be fixed with a pragma directive instead?

[szym, 2012-06-07 17:40:49]

https://chromiumcodereview.appspot.com/10544054/diff/1/net/dns/dns_config_ser...
File net/dns/dns_config_service_win.cc (right):

https://chromiumcodereview.appspot.com/10544054/diff/1/net/dns/dns_config_ser...
net/dns/dns_config_service_win.cc:116: #if defined(OS_WIN) && !defined(NDEBUG)
On 2012/06/07 17:38:46, cbentzel wrote:
> Can this be fixed with a pragma directive instead?

Hmm, how about: http://msdn.microsoft.com/en-us/library/aa985939(v=vs.80).aspx

[jaysoffian, 2012-06-07 18:00:19]

On 2012/06/07 17:40:49, szym wrote:
> On 2012/06/07 17:38:46, cbentzel wrote:
> > Can this be fixed with a pragma directive instead?
> 
> Hmm, how about:
http://msdn.microsoft.com/en-us/library/aa985939%28v=vs.80%29.aspx

It looks like that would do it, but it's not clear to me where the best place is
to define _HAS_ITERATOR_DEBUGGING=0 in the context of this issue.

(Aside, I noticed _HAS_ITERATOR_DEBUGGING=0 is currently used on memcheck, tsan,
and dr memory builds for performance reasons.)

[szym, 2012-06-07 18:02:57]

On 2012/06/07 18:00:19, jaysoffian wrote:
> On 2012/06/07 17:40:49, szym wrote:
> > On 2012/06/07 17:38:46, cbentzel wrote:
> > > Can this be fixed with a pragma directive instead?
> > 
> > Hmm, how about:
> http://msdn.microsoft.com/en-us/library/aa985939%2528v=vs.80%2529.aspx
> 
> It looks like that would do it, but it's not clear to me where the best place
is
> to define _HAS_ITERATOR_DEBUGGING=0 in the context of this issue.
> 
> (Aside, I noticed _HAS_ITERATOR_DEBUGGING=0 is currently used on memcheck,
tsan,
> and dr memory builds for performance reasons.)

Right, this has to be defined before <string> is included to have any effect.
Since the crash happens in UTF16ToASCIII, it would probably have to be in
string_util.h. That said, would you be able to test if the crash still occurs if
you add _HAS_ITERATOR_DEBUGGING=0 before #include <string> in this file
(dns_config_service_win.cc) only?

[jaysoffian, 2012-06-07 18:34:01]

On 2012/06/07 18:02:57, szym wrote:
> Right, this has to be defined before <string> is included to have any effect.
> Since the crash happens in UTF16ToASCIII, it would probably have to be in
> string_util.h. That said, would you be able to test if the crash still occurs
if
> you add _HAS_ITERATOR_DEBUGGING=0 before #include <string> in this file
> (dns_config_service_win.cc) only?

Tried:

  #include "net/dns/dns_config_service_win.h"
  #define _HAS_ITERATOR_DEBUGGING 0

  #include <algorithm>
  #include <string>
  ...

Not un-expectedly, this doesn't help with the crash. I gather that
_HAS_ITERATOR_DEBUGGING has to be defined before anything includes string.

[jaysoffian, 2012-06-07 18:37:50]

Er, actually it was:


  #include "net/dns/dns_config_service_win.h"
  #undef _HAS_ITERATOR_DEBUGGING
  #define _HAS_ITERATOR_DEBUGGING 0

  #include <algorithm>
  #include <string>
  ...

[szym, 2012-06-07 19:26:11]

I think in this case, the current solution makes sense.
WDYT, Chris?

[szym, 2012-06-07 20:19:28]

On 2012/06/07 19:26:11, szym wrote:
> I think in this case, the current solution makes sense.
> WDYT, Chris?

jaysoffian: Could you check if: https://chromiumcodereview.appspot.com/10545065/
solves the issue?

[jaysoffian, 2012-06-07 23:56:53]

On 2012/06/07 20:19:28, szym wrote:
> jaysoffian: Could you check if:
https://chromiumcodereview.appspot.com/10545065/
> solves the issue?

Yup, it does. Ignore this change then.

Thanks!