Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
10441027:
Stub binary for fuzzing DNS resolver. (Closed)
|
Created:
8 years, 7 months ago by Deprecated (see juliatuttle) Modified:
8 years, 6 months ago CC:
chromium-reviews, pam+watch_chromium.org, cbentzel+watch_chromium.org, darin-cc_chromium.org Base URL:
svn://svn.chromium.org/chrome/trunk/src Visibility:
Public. |
DescriptionStub binary for fuzzing DNS resolver.
Initial version doesn't actually read the test case.
BUG=130751
TEST=Built locally (including with ASAN) and ran, and it works
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=140119
Patch Set 1 #
Total comments: 24
Patch Set 2 : Fix szym's comments #
Total comments: 4
Patch Set 3 : #
Total comments: 6
Patch Set 4 : #
Total comments: 2
Patch Set 5 : #
Total comments: 12
Patch Set 6 : Fix cbentzel's comments #Patch Set 7 : #
Total comments: 7
Patch Set 8 : Fix cbentzel's comments (and get the scoped_ptr include right) #Patch Set 9 : Whoa, C++ has *objects* #
Total comments: 2
Patch Set 10 : #Patch Set 11 : #include "base/basictypes.h" #
Total comments: 1
Patch Set 12 : ...it's uint16, not uint16_t. #
Total comments: 1
Patch Set 13 : Put base dependency back #
Messages
Total messages: 28 (0 generated)
https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:1: #include <stdio.h> Add licence. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:14: using namespace net; Don't go using whole namespaces. Probably just put it in namespace net {}. Typically, it'd be: namespace net { namespace { // your stuff } } https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:16: static int usage(const char* progn) { Preferred: "Usage". Expand |program_name|. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:21: #define MAX_DOMAIN 256 const unsigned kMaxDomain. If this is meant to be maximum length of DNS name, use the constant from net::dns_protocol. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:30: FILE* file = fopen(filename, "r"); Consider using file_util. Up to you. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:40: /* XXX: You can overflow domain. */ All comments are //. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:41: fscanf(file, "%hu %s %hu\n", &id, qname_dotted, &qtype); Check that it worked. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:43: printf("Query: id=%hu name=%s type=%hu\n", id, qname_dotted, qtype); What happens to the output? Is it automatically parsed by ClusterFuzz? Will the harness only catch crashes? https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:47: char* response_buf = reinterpret_cast<char*>(malloc(response_len)); No malloc. Use new. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:74: fprintf(stderr, "ParseToAddressList failed: %d\n", result); Should you return an error code here for the harness?
https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:14: using namespace net; On 2012/05/24 19:41:02, szym wrote: > Don't go using whole namespaces. Probably just put it in namespace net {}. > Typically, it'd be: > namespace net { > namespace { > // your stuff > } > } Another option is to just go using net::DnsQuery; using net::DnsResponse; using net::DNSDomainFromDot; https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:24: // base::AtExitManager at_exit_manager; You probably don't need it.
PTAL. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:1: #include <stdio.h> On 2012/05/24 19:41:02, szym wrote: > Add licence. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:14: using namespace net; On 2012/05/24 19:41:02, szym wrote: > Don't go using whole namespaces. Probably just put it in namespace net {}. Will that work if the compiler is expecting to call just "main"? > Typically, it'd be: > namespace net { > namespace { > // your stuff > } > } I just went with specifying net:: before relevant things -- there aren't too many. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:14: using namespace net; On 2012/05/24 19:41:02, szym wrote: > Don't go using whole namespaces. Probably just put it in namespace net {}. > Typically, it'd be: > namespace net { > namespace { > // your stuff > } > } Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:16: static int usage(const char* progn) { On 2012/05/24 19:41:02, szym wrote: > Preferred: "Usage". Expand |program_name|. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:21: #define MAX_DOMAIN 256 On 2012/05/24 19:41:02, szym wrote: > const unsigned kMaxDomain. If this is meant to be maximum length of DNS name, > use the constant from net::dns_protocol. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:24: // base::AtExitManager at_exit_manager; On 2012/05/24 19:42:30, szym wrote: > You probably don't need it. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:26: if (argc < 1) This should've been argc < 2 ;) https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:40: /* XXX: You can overflow domain. */ On 2012/05/24 19:41:02, szym wrote: > All comments are //. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:41: fscanf(file, "%hu %s %hu\n", &id, qname_dotted, &qtype); On 2012/05/24 19:41:02, szym wrote: > Check that it worked. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:43: printf("Query: id=%hu name=%s type=%hu\n", id, qname_dotted, qtype); On 2012/05/24 19:41:02, szym wrote: > What happens to the output? Is it automatically parsed by ClusterFuzz? Will the > harness only catch crashes? The harness only catches crashes. This is just for debugging. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:47: char* response_buf = reinterpret_cast<char*>(malloc(response_len)); On 2012/05/24 19:41:02, szym wrote: > No malloc. Use new. Done. https://chromiumcodereview.appspot.com/10441027/diff/1/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:74: fprintf(stderr, "ParseToAddressList failed: %d\n", result); On 2012/05/24 19:41:02, szym wrote: > Should you return an error code here for the harness? No. This is not an error. We're happy if it returns an error on a malformed packet instead of crashing. At some point, we may add code that allows test cases to specify their expected results, but for now we're just making sure it doesn't crash.
http://codereview.chromium.org/10441027/diff/6001/net/net.gyp File net/net.gyp (right): http://codereview.chromium.org/10441027/diff/6001/net/net.gyp#newcode1692 net/net.gyp:1692: '../base/base.gyp:base', The explicit dependency on base is the same as other targets, but it seems like it should already be handled since the net target depends on it. http://codereview.chromium.org/10441027/diff/6001/net/tools/dns_fuzz_stub/dns... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): http://codereview.chromium.org/10441027/diff/6001/net/tools/dns_fuzz_stub/dns... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:18: static int Usage(const char* program_name) { I don't think there's any hard rules against functions with static linkage in our style guide, but a more common way of doing the same thing is to include these in an anonymous namespace. http://codereview.chromium.org/10441027/diff/6001/net/tools/dns_fuzz_stub/dns... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:45: if (fscanf(file, "%hu %s %hu\n", &id, qname_dotted, &qtype) < 3) { I don't understand why we don't care about overflow here. Either ASAN will catch it, or it will lead to unexpected issues. In either case, how would we be able to distinguish that it's a problem in the test harness rather than the DNS code itself? Seems like it would lead to too many false failures.
PTAL. I mocked out the reading code so we can get this going; I'll replace it with code that reads JSON or something less finicky. (I don't really want to deal with reading a homegrown format with stdio.) https://chromiumcodereview.appspot.com/10441027/diff/6001/net/tools/dns_fuzz_... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/6001/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:18: static int Usage(const char* program_name) { On 2012/05/25 01:53:55, cbentzel wrote: > I don't think there's any hard rules against functions with static linkage in > our style guide, but a more common way of doing the same thing is to include > these in an anonymous namespace. Done.
How do you plan to use this binary while ReadTestCase is a mock? https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:30: bool ReadTestCase(const char* filename, If you intend to land this CL as is, add TODO(ttuttle) explaining that this is a temporary mock. Normally should also file a bug to keep track of those. https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:37: 0x00, 0x00, 0x00, 0xff, 0x00, 0x04, 0x0a, 0x0a, 0x0a, 0x0a }; Use uint8 or unsigned char, so that 0xff and 0x81 are not "overflowing". https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:44: *resp_buf = new char[sizeof(resp)]; arraysize(resp) is preferred and does not assume that sizeof(char) == 1.
On 2012/05/30 22:32:13, szym wrote: > How do you plan to use this binary while ReadTestCase is a mock? I asked Thomas to just do a mocked out version so we can get it up and running on the bots.
https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:30: bool ReadTestCase(const char* filename, On 2012/05/30 22:32:13, szym wrote: > If you intend to land this CL as is, add TODO(ttuttle) explaining that this is a > temporary mock. Normally should also file a bug to keep track of those. Done. https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:37: 0x00, 0x00, 0x00, 0xff, 0x00, 0x04, 0x0a, 0x0a, 0x0a, 0x0a }; On 2012/05/30 22:32:13, szym wrote: > Use uint8 or unsigned char, so that 0xff and 0x81 are not "overflowing". Done. https://chromiumcodereview.appspot.com/10441027/diff/5/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:44: *resp_buf = new char[sizeof(resp)]; On 2012/05/30 22:32:13, szym wrote: > arraysize(resp) is preferred and does not assume that sizeof(char) == 1. Done.
lgtm except a minor issue https://chromiumcodereview.appspot.com/10441027/diff/10002/net/tools/dns_fuzz... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/10002/net/tools/dns_fuzz... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:44: *resp_len = arraysize(resp); This should actually be sizeof :) memcpy expects the size in bytes.
https://chromiumcodereview.appspot.com/10441027/diff/10002/net/tools/dns_fuzz... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/10002/net/tools/dns_fuzz... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:44: *resp_len = arraysize(resp); On 2012/05/31 16:46:11, szym wrote: > This should actually be sizeof :) > memcpy expects the size in bytes. Gah, okay, got it.
http://chromiumcodereview.appspot.com/10441027/diff/9003/net/net.gyp File net/net.gyp (right): http://chromiumcodereview.appspot.com/10441027/diff/9003/net/net.gyp#newcode1701 net/net.gyp:1701: '../base/base.gyp:base', Does this need to explicitly depend on base? Should be included indirectly through dependency on net. http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:59: printf("Test case: %s\n", filename); Should this be going to stdout or stderr? Should this be using the LOG() facility instead, with the support for different levels of logging? http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:72: You should use scoped_array or similar to hold onto resp_buf at this point so you don't leak it. Not a huge deal given that it's a short lived program, but I'd rather be careful. http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:87: printf("InitParse failed.\n"); You are typically using argv[0] as a prefix for the messages. Do you want that here as well? http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:88: return 0; Should this be a non-0 return code? http://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_s... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:96: printf("ParseToAddressList failed: %d\n", result); Same concerns in this error block as in the InitParse case.
https://chromiumcodereview.appspot.com/10441027/diff/9003/net/net.gyp File net/net.gyp (right): https://chromiumcodereview.appspot.com/10441027/diff/9003/net/net.gyp#newcode... net/net.gyp:1701: '../base/base.gyp:base', On 2012/05/31 19:17:13, cbentzel wrote: > Does this need to explicitly depend on base? Should be included indirectly > through dependency on net. Done. https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:59: printf("Test case: %s\n", filename); On 2012/05/31 19:17:13, cbentzel wrote: > Should this be going to stdout or stderr? Should this be using the LOG() > facility instead, with the support for different levels of logging? Moved to LOG. https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:72: On 2012/05/31 19:17:13, cbentzel wrote: > You should use scoped_array or similar to hold onto resp_buf at this point so > you don't leak it. Not a huge deal given that it's a short lived program, but > I'd rather be careful. Alright. I've made a first attempt; let me know if there's a nicer way to do it. (I didn't want to pass the scoped_array to ReadTestCase, so I initialize it from resp_buf after.) https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:87: printf("InitParse failed.\n"); On 2012/05/31 19:17:13, cbentzel wrote: > You are typically using argv[0] as a prefix for the messages. Do you want that > here as well? Switched to LOG. https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:88: return 0; On 2012/05/31 19:17:13, cbentzel wrote: > Should this be a non-0 return code? No. InitParse fails if the ID, question count, or question don't match the query. This is a legitimate failure case for a fuzzed packet. https://chromiumcodereview.appspot.com/10441027/diff/9003/net/tools/dns_fuzz_... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:96: printf("ParseToAddressList failed: %d\n", result); On 2012/05/31 19:17:13, cbentzel wrote: > Same concerns in this error block as in the InitParse case. Again, this can fail if the packet is mangled. If it fails, that's cool -- we just have no response to print, so we note that it failed and exit cleanly.
https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:34: size_t* resp_len, char** resp_buf) { Consider using std::vector<char>* instead of char** + size_t*. https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:47: memcpy(*resp_buf, resp, sizeof(resp)); If you go with std::vector, this can be done with insert(). https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:75: resp.reset(resp_buf); It's probably cleaner to pass &resp (scoped_array*) to ReadTestCase, but probably easiest to just use std::vector as suggested above.
https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:34: size_t* resp_len, char** resp_buf) { On 2012/05/31 21:43:10, szym wrote: > Consider using std::vector<char>* instead of char** + size_t*. Done. https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:47: memcpy(*resp_buf, resp, sizeof(resp)); On 2012/05/31 21:43:10, szym wrote: > If you go with std::vector, this can be done with insert(). Done. https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:75: resp.reset(resp_buf); On 2012/05/31 21:43:10, szym wrote: > It's probably cleaner to pass &resp (scoped_array*) to ReadTestCase, but > probably easiest to just use std::vector as suggested above. Done. https://chromiumcodereview.appspot.com/10441027/diff/9/net/tools/dns_fuzz_stu... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:90: memcpy(response.io_buffer()->data(), resp_buf, resp_len); std::copy! :D Also, implicit conversion from an array to an iterator on that array! :D
LGTM http://codereview.chromium.org/10441027/diff/7004/net/tools/dns_fuzz_stub/dns... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): http://codereview.chromium.org/10441027/diff/7004/net/tools/dns_fuzz_stub/dns... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:5: #include <stdio.h> Do you need stdio.h and stdlib.h anymore?
http://codereview.chromium.org/10441027/diff/7004/net/tools/dns_fuzz_stub/dns... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): http://codereview.chromium.org/10441027/diff/7004/net/tools/dns_fuzz_stub/dns... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:7: #include <string.h> You don't need <string.h> either, but you do need <string>.
LGTM Please either fill in or remove the BUG=/TEST= lines.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ttuttle@chromium.org/10441027/8004
Try job failure for 10441027-8004 (retry) on win for step "compile" (clobber build). It's a second try, previously, step "compile" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ttuttle@chromium.org/10441027/24001
The CQ will fail again. Please, fix types. https://chromiumcodereview.appspot.com/10441027/diff/24001/net/tools/dns_fuzz... File net/tools/dns_fuzz_stub/dns_fuzz_stub.cc (right): https://chromiumcodereview.appspot.com/10441027/diff/24001/net/tools/dns_fuzz... net/tools/dns_fuzz_stub/dns_fuzz_stub.cc:24: uint16_t* id, std::string* qname, uint16_t* qtype, It's just |uint16| not |uint16_t|.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ttuttle@chromium.org/10441027/30002
Try job failure for 10441027-30002 (retry) on win for step "compile" (clobber build). It's a second try, previously, step "compile" failed. http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=win&number...
http://codereview.chromium.org/10441027/diff/30002/net/net.gyp File net/net.gyp (right): http://codereview.chromium.org/10441027/diff/30002/net/net.gyp#newcode1696 net/net.gyp:1696: 'net', It seems you will need to make the dependency on base explicit, for the component build.
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/ttuttle@chromium.org/10441027/19005
Change committed as 140119 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
