ASan ODR failure in ppapi::proxy::TCPSocketResourceConstants::kMaxReadSize

26 views
Skip to first unread message

Chris Palmer

unread,
Mar 1, 2017, 7:10:56 PM3/1/17
to Chromium-dev
I keep getting this ASan ODR failure in ToT (for several days now). Anyone else, or is it just me?

$ ./out/Default/blink_heap_unittests 
=================================================================
==10984==ERROR: AddressSanitizer: odr-violation (0x7f63b125b5c0):
  [1] size=4 'ppapi::proxy::TCPSocketResourceConstants::kMaxReadSize' ../../ppapi/proxy/tcp_socket_resource_constants.cc:10:43
  [2] size=4 'ppapi::proxy::TCPSocketResourceConstants::kMaxReadSize' ../../ppapi/proxy/tcp_socket_resource_constants.cc:10:43
These globals were registered at these points:
  [1]:
    #0 0x49d0d7  (/ssd/chromium/src/out/Default/blink_heap_unittests+0x49d0d7)
    #1 0x7f63af15b2db  (/ssd/chromium/src/out/Default/./libcontent.so+0x2a9d2db)

  [2]:
    #0 0x49d0d7  (/ssd/chromium/src/out/Default/blink_heap_unittests+0x49d0d7)
    #1 0x7f639b34a0bb  (/ssd/chromium/src/out/Default/./libppapi_proxy.so+0x49c0bb)

==10984==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
SUMMARY: AddressSanitizer: odr-violation: global 'ppapi::proxy::TCPSocketResourceConstants::kMaxReadSize' at ../../ppapi/proxy/tcp_socket_resource_constants.cc:10:43
==10984==ABORTING

Lucas Gadani

unread,
Mar 1, 2017, 11:07:24 PM3/1/17
to pal...@chromium.org, Chromium-dev
Not very helpful, but since no one else replied, I've been getting the same error for a while, and I've just been disabling odr violation detection on asan runs.


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

Ken Rockot

unread,
Mar 1, 2017, 11:31:35 PM3/1/17
to Lucas Gadani, Chris Palmer, Chromium-dev, Scott Graham
I would guess this is caused by a recent move[1] of these constant definitions to a separate source_set target which then gets separately linked into multiple link-time dependencies (e.g. component targets) of the test binary, hence multiple definitions. Probably the simplest thing to do here is change that "common" target[2] to a component.

Scott Graham

unread,
Mar 1, 2017, 11:46:44 PM3/1/17
to Ken Rockot, Lucas Gadani, Chris Palmer, Chromium-dev
Oh! I'll take a look.

(Was there a bot failing somewhere that didn't yell at me? 'cuz as always, 🎶 if you liked it you shoulda put a bot on it.)

Ken Rockot

unread,
Mar 1, 2017, 11:52:44 PM3/1/17
to Scott Graham, Chromium-dev, Chris Palmer, Lucas Gadani
I dunno if we enable ODR violation checks on ASAN bots.

In this case nothing is really broken given the usage of these symbols, and this only affects component builds, but I still think it's worth fixing ODR violations when we see them.

Chris Palmer

unread,
Mar 2, 2017, 3:22:34 PM3/2/17
to Ken Rockot, Scott Graham, Chromium-dev, Lucas Gadani
I don't know if it's on a bot, but the build that fails for me is also the only bot that is blocking a CL of mine from landing. But when I click to read its logs, I get a blank screen (...?), so I broke down and did a local build... and found this. :)

Ken Rockot

unread,
Mar 2, 2017, 3:37:11 PM3/2/17
to Chris Palmer, Scott Graham, Chromium-dev, Lucas Gadani
It seems pretty unlikely to me that this is the source of your breakage, so you'll probably want to look elsewhere in the meantime.

Scott Graham

unread,
Mar 2, 2017, 3:39:51 PM3/2/17
to Ken Rockot, Chris Palmer, Chromium-dev, Lucas Gadani
Sorry, fix is here, but not landed yet https://codereview.chromium.org/2727093003/.

Agreed that the current code doesn't seem likely to be causing that sort of problem as it's just some integral constants being defined twice.
Reply all
Reply to author
Forward
0 new messages