1. 这不是“面经”是一份被面试官用真实生产问题反复验证过的安全与系统能力图谱我坐在会议室里手边是刚写完的malloc内存分配模拟代码对面工程师还没合上笔记本就直接切到 Wireshark 抓包界面指着 TLS 握手过程里一个异常的Client Hello扩展字段问“如果这个字段被恶意篡改Docker 容器网络层会拦截还是透传JWT token 在这个链路里哪个环节最可能被劫持”——那一刻我意识到微软这轮技术面试根本不是在考知识点罗列而是在用一套连贯的、可追溯的、带上下文的工程链条检验你是否真的把 Network Security、JWT、SSH、Docker 和 C Memory 这五块拼图嵌进了同一张生产系统的骨架里。这不是“背了就能过”的面试。它考的是当你在 Ubuntu 上用ssh -i key.pem user10.0.0.47登录一台运行着 Docker 的跳板机时从 TCP 连接建立、密钥认证、容器网络路由、JWT token 解析到最终服务进程里一个char *buf malloc(1024)分配的内存块这整条链路上哪一环出错会导致权限越界哪一环的漏洞能被远程利用哪一环的设计缺陷会让日志审计失效关键词Network Security、JWT、SSH、Docker、C Memory不是并列考点而是五个咬合齿轮——少一个整条链就打滑错一个齿整个系统就脱轨。适合谁看如果你正准备大厂后端/云原生/安全方向的面试尤其是涉及基础设施、身份认证或高并发服务的岗位如果你已经工作3–5年但发现自己写 Dockerfile 很熟、调 JWT 库很顺、配 SSH 密钥很6却说不清“为什么不能在容器里用 root 启动 Nginx”“为什么 JWT 的exp字段必须由服务端强校验而非前端控制”“为什么free(buf)后再printf(%s, buf)有时能打印出内容有时段错误”——那这篇复盘就是为你写的。它不教你怎么“答对题”而是带你回到那个会议室看清每一道题背后真实的系统断层、线上事故和防御逻辑。2. Network Security不是考协议栈是考你如何用网络层思维定位一次“看似正常”的连接失败面试官没问 OSI 七层模型也没让画 TCP 三次握手流程图。他打开终端执行了一条命令curl -v https://api.internal.corp:8443/auth/login返回是Failed to connect to api.internal.corp port 8443: Connection refused。然后他问“现在你只有这台开发机Ubuntu 22.04、一个可用的kubectl配置、以及对目标集群有限的只读权限。请告诉我你会怎么一步步排查每一步的依据是什么”这个问题表面是排障实则是 Network Security 能力的立体扫描。它逼你把抽象的安全概念锚定到具体命令、具体输出、具体配置文件上。我当时的排查路径如下每一步都对应一个核心安全认知2.1 第一层确认 DNS 与基础连通性排除“名字没解析”和“网络不通”假象先执行nslookup api.internal.corp # 输出Name: api.internal.corp Address: 10.96.123.45 ping -c 3 10.96.123.45 # 输出100% packet lossDNS 解析成功但 ping 不通。这说明问题不在 DNS而在网络层或更高层策略。这里的关键认知是在 Kubernetes 集群内部ping失败不等于服务不可达。因为很多集群默认禁用 ICMP出于安全加固但 TCP 端口仍可通。所以不能止步于ping。提示面试中若只说“ping 不通所以网络有问题”会被立刻打断。真正要问的是“ICMP 被禁用是常见加固手段那我们该用什么替代方案验证三层连通性”2.2 第二层用telnet或nc验证四层端口可达性直击防火墙与 Service 暴露逻辑nc -zv 10.96.123.45 8443 # 输出Connection refusedConnection refused是关键线索。它意味着IP 可达TCP SYN 包能发出去但目标 IP:Port 上没有进程在监听。这和No route to host路由失败或Timeout防火墙丢包有本质区别。此时问题已从“网络不通”缩小到“服务未启动”或“Service 配置错误”。我立刻切到集群kubectl get svc -n internal | grep auth # 输出auth-api ClusterIP 10.96.123.45 none 8443/TCP 2d kubectl get endpoints -n internal auth-api # 输出No resources foundendpoints为空证实了 Service 没有后端 Pod。接着查 Deploymentkubectl get deploy -n internal auth-api # 输出auth-api 0/1 0 0 3h副本数为 0。再查事件kubectl describe deploy auth-api -n internal | grep Events -A 10 # 输出... FailedCreate: Error creating: pods auth-api-... is forbidden: exceeded quota: compute-resources ...真相浮出水面命名空间的 ResourceQuota 耗尽新 Pod 无法调度。这是典型的“安全策略反噬”——资源配额本为防 DoS 攻击而设但配置不当反而导致服务不可用。2.3 第三层深入 TLS 层理解证书信任链断裂如何伪装成“连接拒绝”面试官追问“如果nc显示Connection timed out而不是refused你的排查路径会变吗”当然会。timeout意味着 SYN 包发出后没收到 SYN-ACK。可能原因包括目标主机防火墙 DROP 规则、云平台安全组未放行、Service 类型为ClusterIP但误从外部访问、甚至 TLS 证书验证失败导致客户端主动断开某些严格模式下。我举了一个真实案例某次部署后iOS App 无法登录Android 正常。抓包发现 iOS 客户端在收到 Server Hello 后立即发送Alert: Handshake Failure。根源是服务器证书的Subject Alternative Name (SAN)缺少DNS:api.internal.corp而 iOS 的 ATSApp Transport Security策略比 Android 更严格强制校验 SAN。这再次印证Network Security 不是“通”或“不通”的二值判断而是不同客户端、不同操作系统、不同 TLS 库版本在同一套网络基础设施上呈现出的差异化行为光谱。注意面试中若只答“检查证书”远远不够。必须说明检查什么openssl s_client -connect api.internal.corp:8443 -servername api.internal.corp、怎么看Verify return code: 0 (ok)vs20 (unable to get local issuer certificate)、以及不同返回码对应的真实故障场景。2.4 关键经验把“安全”从名词还原为动词——它永远发生在具体操作与具体输出之间很多候选人背了一堆“TLS 1.2 更安全”“IPSec 加密隧道”但当面对curl -v的原始输出时却无法关联。真正的 Network Security 能力是你看到Connection refused就能条件反射出endpoints是否为空看到SSL routines:ssl3_get_record:wrong version number就知道是 HTTP 请求打到了 HTTPS 端口看到curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure就明白是客户端支持的 cipher suite 与服务端无交集。这背后是无数次线上排障锤炼出的肌肉记忆安全不是贴在墙上的策略文档而是你敲下kubectl get endpoints后盯着那一行No resources found时脊椎窜起的凉意——因为你知道这行字背后是一个正在告警的 SLO。3. JWT面试官不关心你能不能生成 token只关心你能否在内存里“看见”它的生命周期当面试官把终端切回本地运行起一个简单的 Go Web 服务并让我用 Postman 发送一个带 JWT 的请求时我心里清楚重头戏来了。他没让我写签发逻辑而是直接抛出三个递进式问题“这个 token 的exp是16725312002023-01-01 00:00:00 UTC。如果服务器时间快了 5 分钟会发生什么”“如果我在Authorization: Bearer token头里把token替换成eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c一个公开的、过期的示例 token服务端会返回什么错误为什么不是401 Unauthorized”“假设这个 token 是由一个 C 语言写的微服务解析的jwt_parse()函数返回一个结构体指针jwt_t *jwt。如果我忘了调用jwt_free(jwt)会发生什么”这三个问题像三把手术刀精准解剖了 JWT 在真实系统中的三个致命断层时间同步、错误归因、内存管理。3.1 时间漂移exp校验不是数学题是分布式系统里的物理现实第一个问题直指 JWT 最常被忽视的根基——时间。expexpiration time是 Unix 时间戳服务端校验时是用current_time exp做比较。如果服务器时间快了 5 分钟意味着所有exp在未来 5 分钟内的 token都会被提前判定为“已过期”。用户会看到401 Unauthorized但日志里没有任何异常监控也风平浪静。因为这不是 bug而是物理时钟的误差。解决方案不是“修时间”而是“设计容错”。标准做法是引入leeway宽容期例如// 使用 github.com/golang-jwt/jwt/v5 token, err : jwt.ParseWithClaims(tokenString, claims, keyFunc, jwt.WithValidTime(5*time.Second)) // 允许最多5秒的时钟偏差WithValidTime并非简单地把exp加 5 秒而是将exp和nbfnot before的校验窗口都放宽。这背后是工程权衡绝对的时间一致性在分布式系统中成本极高需 NTP 精密同步而容忍微小偏差带来的安全风险token 多活几秒远小于服务不可用的风险。经验线上环境必须监控 NTP 同步状态。systemctl status systemd-timesyncd或ntpq -p应是 SRE 日常巡检项。曾有个集群因 NTP 服务意外停止导致所有 JWT 认证在凌晨 3 点集中失效告警电话响彻凌晨。3.2 错误码语义HTTP 状态码是服务端与客户端的契约不是随意填写的占位符第二个问题考验对 HTTP 协议和安全设计原则的理解。那个公开的示例 token其 signature 是用secret签的而我们的服务端用的是另一个密钥。jwt-go库在解析时会先 Base64 解码 header/payload再用密钥计算 signature。密钥不匹配Parse会返回*jwt.ValidationError且Errors jwt.ValidationErrorSignatureInvalid ! 0。此时正确的 HTTP 响应应该是401 Unauthorized因为这是身份认证失败的标准语义。但很多框架尤其早期版本会笼统地返回400 Bad Request理由是“token 格式错误”。这是严重的设计缺陷。400暗示客户端可以修正请求比如改个参数而401明确告知客户端“你的凭证无效请重新获取”。更深层的问题是400会掩盖真实的攻击意图。如果攻击者在暴力破解密钥服务端返回400他会以为 token 结构错了继续试其他格式而返回401他立刻明白“签名验证失败”从而转向更危险的timing attack通过响应时间差异推测密钥。面试中我强调必须区分ValidationError的具体类型ValidationErrorExpired→401ValidationErrorSignatureInvalid→401ValidationErrorMalformedBase64 解码失败→400ValidationErrorUnverifiable缺少必要字段→400这不仅是规范更是对抗自动化攻击的第一道防线。3.3 C 语言中的 JWT当 token 解析变成一场与内存的博弈第三个问题把 JWT 拉回 C 的残酷世界。jwt_parse()通常会malloc一块内存来存储解析后的 claims如sub,name,iat并返回指向它的指针。jwt_free()的职责就是free()这块内存。如果忘记调用jwt_free()后果是内存泄漏。但面试官追问“如果这个服务每秒处理 1000 个请求每个 token 解析消耗 2KB 内存一天下来会怎样”计算很简单1000 req/s × 2KB × 3600 s × 24 h 172.8 GB。一台 32GB 内存的机器不到 3 小时就会 OOMOut of Memory触发 Linux OOM Killer随机杀死进程——可能是你的服务也可能是数据库。但这还不是最险的。更危险的是如果jwt_parse()内部用了strdup()复制字符串而jwt_free()忘了free()这些副本那么即使你free(jwt)了主结构体那些字符串内存依然泄露。C 语言没有 GC内存管理的每一个malloc都必须有且仅有一个对应的free且顺序、范围必须精确匹配。我分享了一个血泪教训曾有个 C SDK其jwt_parse()文档里写着“caller must free the returned pointer”但没写清楚claims字段里的字符串是否也需要单独free。团队按惯例只free(jwt)结果压测时内存曲线一路飙升花了两天才定位到strdup的坑。提示在 C 项目中JWT 解析库的选择jwt-cppC或parson轻量 JSON比裸写malloc更安全。但无论选谁必须通读其内存管理文档或直接看源码malloc/free的配对逻辑。4. SSH从ssh-keygen到sshd_config一条命令背后的权限、审计与信任链面试官关掉浏览器打开一个新的终端窗口输入ssh -o StrictHostKeyCheckingno -o UserKnownHostsFile/dev/null user10.0.0.47然后问“这条命令你在生产环境敢用吗为什么如果必须用如何让它变得‘相对安全’”这看似考 SSH 命令参数实则在考你对“信任建立”这一安全基石的理解。StrictHostKeyCheckingno意味着客户端完全不校验服务器的公钥指纹这打开了经典的中间人攻击MITM大门。攻击者只需在网络中劫持 DNS 或 ARP就能伪造一台同名服务器诱骗你连接并窃取所有传输数据包括密码、私钥、甚至后续的scp文件。4.1 SSH 连接的本质一次基于公钥密码学的信任协商SSH 连接建立远不止“输密码登录”那么简单。它包含四个关键阶段算法协商客户端与服务端交换支持的加密算法如aes256-ctr,chacha20-poly1305openssh.com、密钥交换算法如curve25519-sha256,diffie-hellman-group-exchange-sha256、MAC 算法如hmac-sha2-256。这是安全性的第一道门槛——弱算法如arcfour必须禁用。密钥交换KEX双方基于协商的 KEX 算法生成一个共享的会话密钥session key。这个过程是前向安全的PFS即即使服务器私钥日后泄露也无法解密过去的通信。服务器身份认证服务端发送其公钥host key客户端将其与本地~/.ssh/known_hosts中存储的指纹比对。匹配则信任不匹配则警告这就是StrictHostKeyCheckingyes的作用。用户身份认证这才是我们熟悉的“登录”环节支持密码、公钥、键盘交互等多种方式。-o StrictHostKeyCheckingno直接跳过了第 3 步让整个连接建立在“无条件信任”之上违背了 SSH 设计的初衷。4.2 生产环境的“安全妥协”如何在自动化脚本中平衡便利与风险面试官追问“但 CI/CD 流水线里经常需要无交互 SSH 连接。难道每次都要手动确认known_hosts”当然不。正确做法是预置可信的 host key。例如在 Jenkins Agent 初始化脚本中# 获取目标服务器的公钥指纹需人工首次确认 ssh-keyscan -H 10.0.0.47 ~/.ssh/known_hosts # 或更安全只添加特定算法的 key ssh-keyscan -t rsa,ecdsa 10.0.0.47 ~/.ssh/known_hostsssh-keyscan会连接服务器获取其 host key并以hostname key_type base64_key格式输出。追加到known_hosts后后续ssh命令就能自动校验无需-o StrictHostKeyCheckingno。注意ssh-keyscan本身也有 MITM 风险所以它应在可信网络内执行或配合ssh-keygen -lf手动比对指纹。4.3sshd_config服务器端的安全闸门每一行都是防线面试官接着问“如果让你加固一台 Ubuntu 22.04 的 SSH 服务/etc/ssh/sshd_config里你必改的前三项是什么”我的答案是PermitRootLogin no禁止 root 直接登录。这是最基础、最有效的防护。所有管理操作必须通过普通用户sudo完成留下完整的审计日志/var/log/auth.log里会有sudo: user : TTYpts/0 ; PWD/home/user ; USERroot ; COMMAND/bin/bash。PasswordAuthentication no禁用密码登录强制使用密钥认证。密钥强度远高于人类记忆的密码且无法被暴力破解除非私钥泄露。配合PubkeyAuthentication yes这是现代 SSH 的黄金标准。AllowUsers deploy192.168.1.0/24 admin10.0.0.0/8明确指定允许登录的用户和来源 IP 段。比DenyUsers更主动、更安全。它把访问控制从“黑名单”变为“白名单”大幅缩小攻击面。我还补充了两个进阶项ClientAliveInterval 300ClientAliveCountMax 3防止僵尸连接长期占用资源。LogLevel VERBOSE开启详细日志便于追踪异常登录尝试如频繁的Failed password。4.4 实战陷阱ssh命令的“静默失败”与调试技巧最后面试官给了一个真实场景“运维同事说ssh user10.0.0.47一直卡住没报错也没成功。你怎么办”标准答案是加-vverbose参数ssh -v user10.0.0.47它会逐行打印连接过程DNS 解析、TCP 连接、算法协商、KEX、host key 校验、用户认证。卡在哪一步一目了然。但更隐蔽的坑是ssh默认会尝试所有本地私钥~/.ssh/id_rsa,id_ecdsa,id_ed25519如果某个私钥需要密码passphrase而你又没用ssh-agent它就会卡在“Enter passphrase for ...”提示上且-v输出里可能没有明显线索。解决方法是用-o IdentitiesOnlyyes强制只用-i指定的密钥或用-o PreferredAuthenticationspublickey禁用密码等其他认证方式快速失败。这再次印证SSH 的安全始于对每一条命令、每一个参数、每一行日志的敬畏。它不是“配好就行”的功能而是贯穿连接生命周期的、精密的、可审计的信任链。5. Docker从docker run到cgroups容器不是魔法盒子是受控的 Linux 进程当面试官在终端里输入docker run -it --rm ubuntu:22.04 /bin/bash并让我解释“按下CtrlP CtrlQ后容器进程发生了什么变化”时我知道考验底层理解的时刻到了。很多人以为docker ps里看到的容器 ID就是一个黑盒进程。但面试官要听的是runc、cgroups、namespaces这些词背后的真实动作。5.1CtrlP CtrlQ的真相从“前台进程”到“后台守护”一次SIGWINCH的优雅转身CtrlP CtrlQ是 Docker 的 detach 快捷键。它的本质是 Docker Client 向 Docker Daemon 发送一个POST /containers/{id}/attach?detachKeysctrl-p,ctrl-q请求。Daemon 收到后并不会杀死容器内进程而是做两件事解除 stdin/stdout/stderr 的 TTY 绑定容器内/bin/bash进程的文件描述符 0/1/2原本指向一个伪终端pty的 slave 端。detach 后这些 fd 被重定向到/dev/null或一个空管道。bash会感知到read(0, ...)返回 0EOF于是退出。但等等——如果bash退出了容器不就停了关键点--rm和--init的影响--rm只在容器退出时自动删除镜像不影响运行时。而--init或docker run --init才是重点。它会在容器内启动一个轻量 init 进程如tini作为 PID 1。当bash因 EOF 退出tini会接管成为新的前台进程保持容器“活着”。CtrlP CtrlQ后你看到的docker ps里容器仍在运行正是因为tini在那里“站岗”。提示没有--init的容器CtrlP CtrlQ后bash退出PID 1 消失Linux 内核会向所有子进程发送SIGKILL容器立即停止。这是新手常踩的坑。5.2docker run的底层一次runc createrunc start的完整旅程面试官问“docker run -d -p 8080:80 nginxDocker Daemon 内部到底做了什么”我拆解为三步runc createDaemon 调用runc工具根据镜像的config.json由docker image inspect nginx可见创建一个隔离的进程上下文。这包括Namespacespid进程隔离、network网络栈隔离、mount文件系统挂载点隔离、uts主机名隔离、ipc进程间通信隔离。nginx进程在自己的pidnamespace 里看到自己是 PID 1完全不知道宿主机的其他进程。Cgroupscpu限制 CPU 使用率、memory限制内存上限、pids限制最大进程数。docker run -m 512m就是往cgroup.procs里写进程 ID并设置memory.max。runc startruncfork 一个子进程在上述隔离环境中execve(/usr/sbin/nginx, ...)启动 nginx 主进程。端口映射8080:80这并非 Docker 自己实现而是调用宿主机的iptables或nftables规则。docker-proxy进程或iptables规则监听宿主机8080端口将流量 DNATDestination NAT转发到容器的172.17.0.2:80容器 IP。iptables -t nat -L -n可以看到类似DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80的规则。5.3 安全红线为什么--privileged是“核按钮”以及--cap-add的精准授权哲学面试官抛出终极拷问“docker run --privileged ubuntu:22.04它到底获得了什么特权和--cap-addALL有什么本质区别”--privileged是 Docker 的“上帝模式”。它等价于挂载所有宿主机的 cgroup 和 procfs/proc,/sys禁用所有 seccomp、AppArmor、SELinux 安全策略授予所有 Linux capabilitiesCAP_SYS_ADMIN,CAP_NET_ADMIN,CAP_DAC_OVERRIDE等允许访问所有设备/dev/sda,/dev/kvm。这意味着容器内进程可以直接操作宿主机磁盘dd if/dev/zero of/dev/sda修改宿主机网络配置ip link add br0 type bridge加载内核模块insmod /lib/modules/.../kvm.ko。而--cap-addALL只是赋予所有 capabilities但仍受限于 namespaces 和 cgroups。它无法挂载宿主机的/proc无法看到宿主机的进程列表ps aux只能看到容器内进程也无法访问/dev下未显式挂载的设备。真正的安全实践是“最小权限原则”的极致体现需要读取/proc/meminfo--cap-addSYS_PTRACE--volume /proc:/host-proc:ro需要绑定到80端口--cap-addNET_BIND_SERVICE而非--privileged需要运行systemd用--tmpfs /run --tmpfs /run/lock --volume /sys/fs/cgroup:/sys/fs/cgroup:ro而非--privileged。我分享了一个惨痛教训某次为了快速调试给一个 CI 构建容器加了--privileged结果构建脚本里一个rm -rf /本意是清理工作目录误删了宿主机的/。幸亏是测试环境但代价是整整一天的恢复。经验在 CI/CD 中永远用--read-only挂载根文件系统用--tmpfs /tmp提供临时空间。docker run --read-only --tmpfs /tmp:rw,size100m ubuntu:22.04这才是生产级的稳健。6. C Memory从malloc到valgrind内存错误不是“偶尔崩溃”是悬在头顶的达摩克利斯之剑面试官关闭了所有终端打开一个 Vim 窗口里面是一段 20 行的 C 代码#include stdio.h #include stdlib.h #include string.h int main() { char *buf malloc(10); strcpy(buf, Hello, World!); // Oops! 13 chars \0 printf(buf: %s\n, buf); free(buf); printf(After free: %s\n, buf); // Dangling pointer! return 0; }他问“这段代码在你的 Ubuntu 22.04 机器上gcc -o test test.c ./test会输出什么为什么如果加上-fsanitizeaddress编译又会怎样”这是一个关于 C 语言内存模型的终极拷问。它不考语法而考你是否真正理解malloc/free背后的操作系统机制。6.1strcpy越界从“缓冲区溢出”到“堆元数据破坏”的连锁反应malloc(10)请求 10 字节但glibc的malloc实现ptmalloc2会额外分配一些元数据metadata用于管理内存块。典型布局是[Prev Size][Size][User Data (10 bytes)][Next Size][Next Ptr]...strcpy(buf, Hello, World!)试图复制 14 字节13 字符 \0到只有 10 字节的User Data区域。这必然覆盖后面的Next Size字段。后果是灾难性的如果Next Size被覆盖为一个极小的值如0x00000001free(buf)时malloc会尝试合并相邻块但读取到错误的Next Size导致free()内部崩溃double free or corruption。如果Next Size被覆盖为一个极大的值free()可能跳过大片内存造成隐性泄漏。更糟的是它可能破坏malloc的内部链表fastbins,unsorted bins导致后续所有malloc/free行为不可预测。这就是为什么“越界写”比“越界读”危险得多——它污染的是内存管理器的“大脑”而非仅仅是数据。6.2free后的printf悬垂指针Dangling Pointer的幽灵行为free(buf)后buf指针并未被置为NULL它仍然指向那块已被释放的内存地址。这块内存的归属权已交还给malloc但内容尚未被覆盖。所以printf(After free: %s\n, buf)很可能还能打印出Hello, World!——这不是“正常”而是“侥幸”。这种行为叫Undefined Behavior (UB)。C 标准对此不做任何保证。它可能在你的机器上正常打印因为内存没被重用在另一台机器上打印乱码因为内存被部分覆盖直接段错误Segmentation Fault因为那块内存已被mmap释放访问触发SIGSEGV甚至“正常”运行但悄悄破坏了其他变量如果那块内存后来被分配给另一个malloc。UB 是 C 语言最险恶的特性。它让 bug 具有“延迟性”和“随机性”极难复现和调试。6.3 工具链用valgrind和AddressSanitizer把 UB 变成可定位的错误面试官问“如何在开发阶段就捕获这类错误”我的答案是双工具组合valgrind --toolmemcheck ./test这是老牌内存检测神器。它会报告12345 Invalid write of size 1 12345 at 0x4C30F34: strcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 12345 by 0x10874B: main (test.c:8) 12345 Address 0x4a4a4a4a4a4a4a4a is not stackd, mallocd or (recently) freed 12345 12345 Invalid read of size 1 12345 at 0x4C310A4: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 12345 by 0x4EABF4F: puts (ioputs.c:35) 12345 by 0x10875F: main (test.c:10)gcc -fsanitizeaddress -g test.c -o test ./testAddressSan
