Opened 4 years ago

Closed 20 months ago

#6516 closed defect (fixed)

tsan symbols are broken with NASM

Reported by: Clément Bœsch Owned by:
Priority: normal Component: build system
Version: unspecified Keywords: regression tsan
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Since the switch from YASM to NASM, thread sanitizer is unusable by default:

WARNING: ThreadSanitizer: data race (pid=21662)
  Read of size 8 at 0x7b9800003008 by main thread (mutexes: write M1355):
    #0 <null> <null> (libtsan.so.0+0x000000030111)
    #1 <null> <null> (ffmpeg+0x000000d5481f)
    #2 <null> <null> (ffmpeg+0x000000d054e1)
    #3 <null> <null> (ffmpeg+0x000000e134d7)
    #4 <null> <null> (ffmpeg+0x000000e13ba8)
    #5 <null> <null> (ffmpeg+0x000000a1553f)
    #6 <null> <null> (ffmpeg+0x000000a1609a)
    #7 <null> <null> (ffmpeg+0x00000050e4e4)
    #8 <null> <null> (ffmpeg+0x000000510bb5)
    #9 <null> <null> (ffmpeg+0x0000004d6d3b)
    #10 <null> <null> (libc.so.6+0x000000020439)

This may be related to the way NASM stores dwarf symbols.

Note: tested only with gcc-tsan.

Note: we probably need to open a ticket on the NASM bugtracker if it's concluded we didn't mixed up incompatible options in our build system. Still, I consider this a regression since NASM wasn't the default previously.

Workaround: use --x86asmexe=yasm.

Change History (4)

comment:1 by Clément Bœsch, 4 years ago

Summary: tsan symbols broken are broken with NASMtsan symbols are broken with NASM

comment:2 by Balling, 2 years ago

Status: newopen

Did you open the bug in NASM?

comment:3 by Carl Eugen Hoyos, 21 months ago

How can I reproduce this (with nasm)?

comment:4 by Clément Bœsch, 20 months ago

Resolution: fixed
Status: openclosed

I cannot reproduce the issue anymore, so I suppose it was fixed at some point during these years. I should be able to drop YASM from my FATE instances now.

Note: See TracTickets for help on using tickets.