This is an automated email from the ASF dual-hosted git repository.
yiguolei pushed a commit to branch branch-4.1
in repository https://gitbox.apache.org/repos/asf/doris.git
The following commit(s) were added to refs/heads/branch-4.1 by this push:
new 3da992cf2e2 branch-4.1: [fix](thirdparty) Repair the libunwind
phdr-cache patch mangled in the #64093 backport (#67564)
3da992cf2e2 is described below
commit 3da992cf2e2de4d958365750a0d757fa26921620
Author: Mingyu Chen (Rayner) <[email protected]>
AuthorDate: Mon Sep 7 18:20:48 2026 +0800
branch-4.1: [fix](thirdparty) Repair the libunwind phdr-cache patch mangled
in the #64093 backport (#67564)
### What problem does this PR solve?
Problem Summary:
Every branch-4.1 PR that touches `thirdparty/` fails `Build Third Party
Libraries (macOS-arm64)` after two to three minutes, inside
`download-thirdparty.sh`, long before anything is compiled:
```
patching file 'src/dwarf/Gfind_proc_info-lsb.c'
2 out of 2 hunks failed--saving rejects to
'src/dwarf/Gfind_proc_info-lsb.c.rej'
##[error]Process completed with exit code 1.
```
| PR | base | `Build Third Party Libraries (macOS-arm64)` |
|---|---|---|
| #67378 | branch-4.1 | fail, 5m18s — these hunks |
| #67356 | branch-4.1 | fail, 3m11s — these hunks |
| #67523 | branch-4.1 | fail, 2m43s — these hunks |
| #67554 | branch-4.1 | fail, 2m43s — these hunks |
| **#67535** — same change as #67523 | **master** | **pass, 2h26m full
build** |
The last row is the point: the same content passes on master and dies in
the patch step on branch-4.1.
**Root cause.**
`thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch` is corrupt
on this branch. It arrived that way in `4439e6f6b46` (the backport of
#64093) and does not match the file master carries (`dc70115a432`) —
even though both branches pin the same libunwind 1.6.2 with the same md5
and run byte-identical patching code in `download-thirdparty.sh`.
In master's copy the blank lines around the change are **context**
lines, each a line holding a single space. In this branch's copy they
are **deletion** lines (`-` with nothing after it), with the hunk
headers renumbered to match that reading (`@@ -46,3 +46,8 @@` instead of
`@@ -47,6 +47,14 @@`, `@@ -805,5 +810,6 @@` instead of `@@ -804,7
+812,10 @@`) and the trailing context dropped. That is what a
trailing-whitespace strip followed by a hand repair leaves behind. The
patch now asks `patch(1)` to delete blank lines that the real source
does not have at those offsets.
**Why only macOS.** GNU patch on the Linux runner recovers from it —
`Hunk #1 succeeded at 12 with fuzz 1` — and the Linux job passes, which
is why this went unnoticed for a week. The macOS runner's `patch`
rejects both hunks and `download-thirdparty.sh` exits 1.
**Fix.** Take master's copy verbatim. One file, nothing else.
### Release note
None
### Check List (For Author)
- Test
- [ ] Regression test
- [ ] Unit Test
- [x] Manual test (add detailed scripts or steps below)
Verified against the pinned tarball (`libunwind-1.6.2.tar.gz`, md5
`f625b6a98ac1976116c71708a73dc44a`) with the same patch implementation
the runner uses (`patch 2.0-12u11-Apple`), on two pristine copies of the
extracted source:
| patch file | exit | result |
|---|---|---|
| this branch's current file | **1** | `2 out of 2 hunks failed` —
byte-identical to the CI message |
| this PR's file | **0** | applies cleanly, no `.rej` |
After applying, the weak declaration and the fork land where
`be/src/common/phdr_cache.cpp` expects them:
```
54:extern int doris_unwind_iterate_phdr (int (*callback) (struct
dl_phdr_info *, size_t, void *),
55: void *data, unw_word_t ip)
__attribute__ ((weak));
...
815: if (doris_unwind_iterate_phdr)
816: ret = doris_unwind_iterate_phdr (dwarf_callback, &cb_data, ip);
817: else
818: ret = dl_iterate_phdr (dwarf_callback, &cb_data);
```
This branch does define that symbol
(`be/src/common/phdr_cache.cpp:249`), so the fix restores the intended
behaviour rather than being a no-op. Linux builds were already getting
it via fuzz, so no behaviour changes there.
- Behavior changed:
- [x] No. Linux already applied this patch (with fuzz); this only makes
the macOS thirdparty build stop failing.
- Does this need documentation?
- [x] No.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01DzUYFcGHQH3bnLGCjpncVj
Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
---
.../patches/libunwind-1.6.2-doris-phdr-cache.patch | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch
b/thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch
index b0b8772e9eb..e534780b725 100644
--- a/thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch
+++ b/thirdparty/patches/libunwind-1.6.2-doris-phdr-cache.patch
@@ -2,10 +2,10 @@ diff --git a/src/dwarf/Gfind_proc_info-lsb.c
b/src/dwarf/Gfind_proc_info-lsb.c
index 1d0d6a4..8f47463 100644
--- a/src/dwarf/Gfind_proc_info-lsb.c
+++ b/src/dwarf/Gfind_proc_info-lsb.c
-@@ -46,3 +46,8 @@ struct table_entry
--
+@@ -47,6 +47,14 @@ struct table_entry
+
#ifndef UNW_REMOTE_ONLY
--
+
+/*
+ * Doris provides a lock-free PHDR snapshot for GNU libunwind. This avoids
+ * entering glibc dl_iterate_phdr from jemalloc profiling or signal-context
@@ -13,8 +13,13 @@ index 1d0d6a4..8f47463 100644
+ */
+extern int doris_unwind_iterate_phdr (int (*callback) (struct dl_phdr_info *,
size_t, void *),
+ void *data, unw_word_t ip)
__attribute__ ((weak));
-@@ -805,5 +810,6 @@ dwarf_find_proc_info (unw_addr_space_t as, unw_word_t ip,
--
++
+ #ifdef __linux__
+ #include "os-linux.h"
+ #endif
+@@ -804,7 +812,10 @@ dwarf_find_proc_info (unw_addr_space_t as, unw_word_t ip,
+ cb_data.di_debug.format = -1;
+
SIGPROCMASK (SIG_SETMASK, &unwi_full_mask, &saved_mask);
- ret = dl_iterate_phdr (dwarf_callback, &cb_data);
+ if (doris_unwind_iterate_phdr)
@@ -22,4 +27,5 @@ index 1d0d6a4..8f47463 100644
+ else
+ ret = dl_iterate_phdr (dwarf_callback, &cb_data);
SIGPROCMASK (SIG_SETMASK, &saved_mask, NULL);
--
+
+ if (ret > 0)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
