Closed paulfloyd closed 4 years ago
In mstacks.c void VG(stack_limits)(Addr SP, Addr start, Addr end )
this executes
if (UNLIKELY((!stackseg->hasR || !stackseg->hasW)
&& (stackseg->kind != SkResvn || stackseg->smode != SmUpper))) {
VG_(debugLog)(2, "stacks",
"segment for SP %p is not RW or not a SmUpper Resvn\n",
(void*)SP);
*start = 0;
*end = 0;
return;
}
which might mean that
init_resvn(&seg, aspacem_vStart, aspacem_vStart + VKI_PAGE_SIZE - 1);
needs changing in aspcemgr
Alternatively this could be another manifestation of the RO memory mapping.
On x86, it core dumps at
#0 0x380869e8 in vgPlain_get_StackTrace_wrk (tid_if_known=1, ips=0x383791d4 <make_ec.ips>, max_n_ips=58, sps=0x0, fps=0x0,
startRegs=0x38376bc8 <vgPlain_interim_stack+1055376>, fp_max_orig=0) at m_stacktrace.c:374
#1 0x38086edd in vgPlain_get_StackTrace_with_deltas (tid=1, ips=0x383791d4 <make_ec.ips>, n_ips=58, sps=0x0, fps=0x0, first_ip_delta=0, first_sp_delta=0)
at m_stacktrace.c:1574
#2 0x38086f99 in vgPlain_get_StackTrace (tid=1, ips=0x383791d4 <make_ec.ips>, max_n_ips=58, sps=0x0, fps=0x0, first_ip_delta=0) at m_stacktrace.c:1586
#3 0x380608d9 in make_ec (tid=1, exclude_first_entry=0 '\000') at ms_main.c:584
#4 0x380606e2 in add_heap_xt (tid=1, req_szB=4096, exclude_first_entry=0 '\000') at ms_main.c:612
#5 0x380605b1 in record_block (tid=1, p=0x400000, req_szB=4096, slop_szB=0, exclude_first_entry=0 '\000', maybe_snapshot=1 '\001') at ms_main.c:1154
#6 0x380604b3 in ms_record_page_mem (a=4194304, len=4096) at ms_main.c:1458
#7 0x3805e582 in ms_new_mem_startup (a=4194304, len=4096, rr=1 '\001', ww=0 '\000', xx=0 '\000', di_handle=0) at ms_main.c:1497
#8 0x381bd82f in valgrind_main (argc=14, argv=0xffbfea20, envp=0xffbfea5c) at m_main.c:1961
#9 0x381bb54b in _start_in_C_freebsd (pArgc=0xffbfea1c, initial_sp=0x0) at m_main.c:3379
which is
if (fp_min <= uregs.xbp &&
uregs.xbp <= fp_max - 1 * sizeof(UWord)/*see comment below*/ &&
VG_IS_4_ALIGNED(uregs.xbp))
{
Addr old_xsp;
/* fp looks sane, so use it. */
uregs.xip = (((UWord*)uregs.xbp)[1]);
because uregs.xbp is 0. Also, fp_min is 0, and fp_max is 0 (and unsigned!)
Without a thorough understanding of what's really wrong here, I made the following change, to catch the case of fp_max == 0
diff --git a/coregrind/m_stacktrace.c b/coregrind/m_stacktrace.c
index 2aabc9085..57edb726d 100755
--- a/coregrind/m_stacktrace.c
+++ b/coregrind/m_stacktrace.c
@@ -238,14 +238,14 @@ UInt VG_(get_StackTrace_wrk) ( ThreadId tid_if_known,
if (fp_min + 512 >= fp_max) {
/* If the stack limits look bogus, don't poke around ... but
don't bomb out either. */
-# elif defined(VGO_solaris)
+# elif defined(VGO_solaris) || defined(VGO_freebsd)
if (fp_max == 0) {
/* VG_(get_StackTrace)() can be called by tools very early when
various tracing options are enabled. Don't proceed further
if the stack limits look bogus.
*/
# endif
-# if defined(VGO_linux) || defined(VGO_solaris)
+# if defined(VGO_linux) || defined(VGO_solaris) || defined(VGO_freebsd)
if (sps) sps[0] = uregs.xsp;
if (fps) fps[0] = uregs.xbp;
ips[0] = uregs.xip;
I don't know if it should really fall into the fp_min + 512 >= fp_max
case (Linux) or the fp_max == 0
case (Solaris), but having chosen to match the Solaris case it passes the regression tests:
$ perl tests/vg_regtest massif/tests
-- Running tests in massif/tests --------------------------------------
[...]
-- Finished tests in massif/tests --------------------------------------
== 37 tests, 0 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 0 post failures ==
We can always reopen the issue if problems arise.
Pushed: To https://github.com/paulfloyd/freebsd_valgrind.git 9748df5f6..286f8e463 freebsd -> freebsd
No stack trace yet
Also pages_as_heap