|
From: Earl C. <ear...@ya...> - 2016-07-04 16:13:38
|
> I believe I have found a problem with handling of signals in a
> multithreaded program.
Here is a candidate patch against 3.11, though I'm unsure if it's taking
the right approach:
+ /home/earl/bin/git diff coregrind/m_signals.c
diff --git a/coregrind/m_signals.c b/coregrind/m_signals.c
index e105afa..66fffa9 100644
--- a/coregrind/m_signals.c
+++ b/coregrind/m_signals.c
@@ -2515,10 +2515,11 @@ Bool VG_(extend_stack)(ThreadId tid, Addr addr)
VG_(debugLog)(1, "signals",
"extending a stack base 0x%lx down by %lu\n",
seg_next->start, udelta);
+
+ Addr new_stack_base = seg_next->start - udelta;
Bool overflow;
if (! VG_(am_extend_into_adjacent_reservation_client)
( seg_next->start, -(SSizeT)udelta, &overflow )) {
- Addr new_stack_base = seg_next->start - udelta;
if (overflow)
VG_(umsg)("Stack overflow in thread #%u: can't grow stack to
%#lx\n",
tid, new_stack_base);
@@ -2530,7 +2531,7 @@ Bool VG_(extend_stack)(ThreadId tid, Addr addr)
/* When we change the main stack, we have to let the stack handling
code know about it. */
- VG_(change_stack)(VG_(clstk_id), addr, VG_(clstk_end));
+ VG_(change_stack)(VG_(clstk_id), new_stack_base, VG_(clstk_end));
if (VG_(clo_sanity_level) > 2)
VG_(sanity_check_general)(False);
Earl
|