Compile failure with optimized ASan builds

[nth10sd]

I ran cmake -S ~/trees/hermes/ -B opt_asan_hermes -G Ninja -DCMAKE_BUILD_TYPE=Release -D HERMES_ENABLE_ADDRESS_SANITIZER=ON to try and get a optimized ASan build, then cmake --build opt_asan_hermes/ to try building it. It fails at:

[249/726] Generating InternalBytecode.hbc
FAILED: lib/InternalBytecode/InternalBytecode.hbc /home/skygentoo/trees/compile-hermes/opt_asan_hermes/lib/InternalBytecode/InternalBytecode.hbc 
cd /home/skygentoo/trees/hermes/lib/InternalBytecode && /home/skygentoo/trees/compile-hermes/opt_asan_hermes/bin/hermesc -O -Wno-undefined-variable -g0 -emit-binary -out=/home/skygentoo/trees/compile-hermes/opt_asan_hermes/lib/InternalBytecode/InternalBytecode.hbc /home/skygentoo/trees/compile-hermes/opt_asan_hermes/lib/InternalBytecode/InternalBytecode.js

=================================================================
==16114==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 73728 byte(s) in 1 object(s) allocated from:
    #0 0x7f5dc62dbeaf in __interceptor_malloc /var/tmp/portage/sys-devel/gcc-13.2.1_p20230826/work/gcc-13-20230826/libsanitizer/asan/asan_malloc_linux.cpp:69
    #1 0x564f8e89537a in RegisterHandlers() (/home/skygentoo/trees/compile-hermes/opt_asan_hermes/bin/hermesc+0xf637a)

SUMMARY: AddressSanitizer: 73728 byte(s) leaked in 1 allocation(s).

Tested on rev b538d92, Dec 19, 2023 build. The other modes (debug, opt, debug ASan) work just fine, as per the README. I understand that this mode (opt ASan) is not in the README - my question is, will this mode ever be supported?

Other versions:

clang version 16.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm/16/bin
Configuration file: /etc/clang/clang.cfg
cmake version 3.27.7

CMake suite maintained and supported by Kitware (kitware.com/cmake).

gcc (Gentoo 13.2.1_p20230826 p7) 13.2.1 20230826
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

git version 2.41.0

Ninja version:
1.11.1

Python 3.11.6

Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon.  Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.

Compiled with gcc 13.1.1 20230527 for Unix (Linux ELF) on Jun 22 2023.

Zip special compilation options:
	USE_EF_UT_TIME       (store Universal Time)
	BZIP2_SUPPORT        (bzip2 library version 1.0.8, 13-Jul-2019)
	    bzip2 code and library copyright (c) Julian R Seward
	    (See the bzip2 license for terms of use)
	SYMLINK_SUPPORT      (symbolic links supported)
	LARGE_FILE_SUPPORT   (can read and write large files on file system)
	ZIP64_SUPPORT        (use Zip64 to store large files in archives)
	UNICODE_SUPPORT      (store and read UTF-8 Unicode paths)
	STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
	UIDGID_NOT_16BIT     (old Unix 16-bit UID/GID extra field not used)
	[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)

Encryption notice:
	The encryption code of this program is not copyrighted and is
	put in the public domain.  It was originally written in Europe
	and, to the best of our knowledge, can be freely distributed
	in both source and object forms from any country, including
	the USA under License Exception TSU of the U.S. Export
	Administration Regulations (section 740.13(e)) of 6 June 2002.

Zip environment options:
             ZIP:  [none]
          ZIPOPT:  [none]

[tmikov]

Just tried and couldn't reproduce on MacOS. Will try Linux next.

[tmikov]

Does not reproduce on Linux with CLang. Must be GCC specific.

[tmikov]

Hi, @nth10sd. I was able to reproduce this on Linux with gcc. The fix is in #1227 .

I understand that this mode (opt ASan) is not in the README - my question is, will this mode ever be supported?

It depends on what you mean by "supported". We are not proactively testing the configuration "gcc+opt+ASAN+Linux" and have no plans to change that for now, since we don't use it ourselves. So, we can't guarantee that we will always investigate and address reports like this one promptly (in this case, I got just curious and dug a little, but I don't always have the time). Mostly, we expect improvements and bugfixes for such cases from the community, in the form of PRs.

OTOH, "clang+opt+ASAN+MacOS" is much higher on our list of priorities.

Generally speaking, as an open source project, we can't provide real support for building the project. It is all best effort. We do our best to make it buildable and runnable on as wide possible set of platforms and compilers, but ultimately it has to be assumed that developers trying to build Hermes (as opposed to just use it) can deal with the associated challenges. That goes double for running in ASAN mode. Hopefully devs who want to run Hermes with ASAN can help us with diagnosing and fixing the associated problems.

So, for example, if someone wanted to build and run Hermes on OpenBSD, we couldn't help with that, or "support" that case. But if they submitted a well documented PR, we would gladly accept it.

[nth10sd]

It depends on what you mean by "supported". We are not proactively testing the configuration "gcc+opt+ASAN+Linux" and have no plans to change that for now, since we don't use it ourselves. So, we can't guarantee that we will always investigate and address reports like this one promptly (in this case, I got just curious and dug a little, but I don't always have the time).

Understood, thanks for fixing this one!