Bug 258556 - devel/llvm12: overwriting static memory
Summary: devel/llvm12: overwriting static memory
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Brooks Davis
Depends on:
Reported: 2021-09-17 10:41 UTC by Dirk Meyer
Modified: 2021-09-19 06:42 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (brooks)

Testport (6.91 KB, text/plain)
2021-09-17 10:46 UTC, Dirk Meyer
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Meyer freebsd_committer 2021-09-17 10:41:42 UTC
With OpenSSL from ports I build a new version of tinyfuge (5.1.1):
Sources: https://github.com/ingwarsw/tinyfugue

The compiled code fails on starting the SSL connection.

% Trying to connect to ap: XXXX:f840::42 8889.
% SSL: cert verify depth exceeded: allowed=0 actual=2
% SSL: cert verify error: err=22 'certificate chain too long' depth:2 cn:/C=US/O=Internet
    Security Research Group/CN=ISRG Root X1
% Intermediate connection to ap failed: SSL/lib: error:1416F086:SSL

While debugging with gcc the static memory of the application gets overwritten.
ssl_options is overwritten with bad data.

The code of the application seems fine, -Wall does not show any hints.
Once I enabled "-g" in CFLAGS the application runs.

% Trying to connect to ap: XXXX:f840::42 8889.
% SSL: chain: depth:2 cn:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
% SSL: chain: depth:1 cn:/C=US/O=Let's Encrypt/CN=R3
% SSL: chain: depth:0 cn:/CN=ap.XXXX.org
% SSL: cert verified: OK ret=0
% Connected to ap using cipher TLS_AES_256_GCM_SHA384.

I tested a few compilers:
clang version 10.0.1 (base)
clang version 12.0.1 (devel/llvm12)
gcc10 (FreeBSD Ports Collection) 10.3.0

The Problem happens with:
clang -O1
clang12 -O1

The application runs with:
clang -g
clang -O0
clang12 -O0
gcc10 -O2
gcc10 -O3

The structure on FreeBSD 12.2 has an address of:
0x7fffffffe4c0  (fail)
0x7fffffffe340  (ok)
I guess there is something going wrong with the memory mapping.
Comment 1 Dirk Meyer freebsd_committer 2021-09-17 10:46:34 UTC
Created attachment 227960 [details]
Comment 2 Brooks Davis freebsd_committer 2021-09-17 20:08:50 UTC
Could you try compiling with clang12 adding -fsanitize=address,undefined? While compiler bugs are certainly possible it seems more likely that clang is finding some undefined behavior and optimizing it into a broken executable.
Comment 3 Dirk Meyer freebsd_committer 2021-09-19 06:42:04 UTC
the Sanitizer found the alignment problems at run time.
Fixing the application soled all the issues.