MASM quickSort过程栈溢出问题求助

Sounds like you're hitting classic quicksort pitfalls that pop up in assembly implementations—let's walk through the most likely causes and fixes, since your array size (max 200) shouldn't trigger stack overflow if the logic is solid.

1. Worst-Case Recursion Depth Is Killing You #

Quicksort's stack usage depends entirely on how evenly your pivot splits the array. If you're picking a lazy pivot (like the first or last element every time), sorted or reverse-sorted input will force recursion depth equal to the array size (200 calls in your case). Each recursive call pushes registers, return addresses, and local vars to the stack—VS's default stack size can't handle that many nested calls.

• Quick Fix: Switch to median-of-three pivot selection (grab first, middle, last elements, pick the median as pivot) or just pick the middle element of the subarray. Even a random pivot will avoid worst-case depth.

2. Stack Frame Imbalances #

MASM demands precise stack management. If your quickSort or partition procedure isn't balancing pushes and pops properly, every recursive call leaks stack space. Over 200 calls, that adds up fast.

• Check These:
  • Did you remember to push ebp and mov ebp, esp at the start, then pop ebp before ret?
  • Are all local variables allocated with sub esp, [size] and restored with add esp, [size] before returning?
  • Do you have any stray push instructions without matching pops (or accounting for them in add esp)?

3. Off-by-One Errors Causing Infinite Recursion #

A tiny mistake in partition bounds will make your code recurse forever on the same subarray, which instantly overflows the stack. Common examples:

• Calling quickSort on low to pivot instead of low to pivot-1 after partitioning
• Calling it on pivot to high instead of pivot+1 to high
• This makes the code keep processing the same elements over and over until the stack dies.
• Fix: After partitioning, double-check that your recursive calls use the adjusted bounds. Print out the low and high values for each call during debugging to spot this.

4. Large Local Variables on the Stack #

If you're allocating temporary arrays or big buffers inside quickSort or partition, each recursive call adds that to the stack. Even a 10-byte buffer multiplied by 200 calls is 2000 bytes—add that to all the other stack overhead, and you're over the limit.

• Fix: Move temp storage to the heap (use HeapAlloc/HeapFree from kernel32) or pass a single buffer from the main procedure instead of allocating per recursive call.

VS Debugging Hacks to Pinpoint the Issue #

• Break on stack overflow: Go to Debug > Windows > Breakpoints, create a new breakpoint at _chkstk—this will stop exactly when the stack is being checked for overflow, so you can look at the call stack to see how deep the recursion is and what parameters are being passed.
• Inspect the call stack: When the program breaks, check the call stack window. You'll see every quickSort call and can hover over the parameters to see low/high values—this will tell you if you're stuck in infinite recursion or just have way too many nested calls.
• Add debug prints: Throw in a simple debug routine to print the pivot value and subarray bounds each time quickSort is called. This will immediately show if you're picking bad pivots or passing wrong bounds.

Since your code works in some cases, it's almost certainly a worst-case scenario (like sorted input) or a subtle off-by-one that only triggers with specific array sizes. Start with checking recursion depth and pivot selection—those are the most likely culprits.

内容的提问来源于stack exchange，提问作者H.W.D