-
Notifications
You must be signed in to change notification settings - Fork 633
frontend stack overflow #21355
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
can be reproduced locally on main. Just |
Encountered in https://buildkite.com/risingwavelabs/pull-request/builds/72480#019634d0-b5a7-4cde-ab18-ab947daa6ec8 as well. Can't reproduce locally for me. |
Stacktrace: 690 frames. Seems easy to exceed 8MB stack size
|
script
import lldb
target = lldb.debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
frame_count = thread.GetNumFrames()
sp_list = []
# 收集每一帧的 SP
for i in range(frame_count):
frame = thread.GetFrameAtIndex(i)
sp = frame.GetSP()
sp_list.append((i, sp, frame))
# 计算并打印每一帧的堆栈大小
print(f"{'Frame':<6} {'Function':<30} {'SP':<18} {'Frame Size'}")
print("-" * 70)
for i in range(len(sp_list) - 1):
idx, sp, frame = sp_list[i]
next_sp = sp_list[i + 1][1]
size = next_sp - sp # 注意:stack grows downward,next_sp > sp
print(f"{idx:<6} {frame.GetFunctionName():<30} 0x{sp:016x} {size} bytes")
# 最后一帧可能没有“下一个”帧可比,标记为 N/A
idx, sp, frame = sp_list[-1]
print(f"{idx:<6} {frame.GetFunctionName():<30} 0x{sp:016x} N/A")
Found
|
StreamProject size =304, StreamFilter =224 PlanBase = 184 |
I think this will only happen in debug mode (
Otherwise, there should be <1k size for each frame I guess it's caused by #21029, which adds logic to |
Great analysis, thanks!! |
Tried in release mode, 1856 bytes (vs 3,616 bytes before). Larger than I imagine, so maybe still worth optimizing later.
|
When I encountered similar problems in the past, I would identify the heaviest part of the execution stack and grow it using the method introduce in #16279. However, based on your testing, it seems this issue is unlikely to occur in production with an optimized build. So this might be not necessary any more...? |
🤔 Oh... it seems I mistakenly thought #16279 is used to allow "deeper stack" instead of "larger stack memory". 🤡🤡🤡🤡🤡 But I see the
However, for this specific issue, I guess it cannot be prevented, as there's no "recursion", but a deep plan with many different plan nodes. (Unless we make a wrapper over |
Buildkite URL
https://buildkite.com/risingwavelabs/pull-request/builds/72323#019623bd-04cc-443a-b9d5-315c4fbb90ce
Description and Insights
No response
The text was updated successfully, but these errors were encountered: