This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/12121] Apparent non-determinism in DWARF symbol resolution
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sources dot redhat dot com
- Date: Thu, 14 Oct 2010 18:13:34 +0000
- Subject: [Bug translator/12121] Apparent non-determinism in DWARF symbol resolution
- Auto-submitted: auto-generated
- References: <bug-12121-1110@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=12121
Josh Stone <jistone at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |jistone at redhat dot com
--- Comment #8 from Josh Stone <jistone at redhat dot com> 2010-10-14 18:12:59 UTC ---
I managed to reproduce the non-determinism with a much smaller test:
$ cat xulcast.stp
probe begin {
println(@cast(0, "JSContext", @1)->regs)
println(@cast(0, "JSObject", @1)->fslots)
}
$ stap -vvv -p2 xulcast.stp $PWD/libxul.so
The success of this is extremely variable. The only consistency is that the
two @casts always succeed or fail together, never one without the other.
The difference I found with the extra verbosity is in these lines:
literal_stmt_for_pointer: finding value for JSContext(SRCFILE)
literal_stmt_for_pointer: finding value for JSObject(SRCFILE)
The SRCFILE varies from run to run, with only some apparently having good type
information. I still don't know why our choice of SRCFILE would vary, as I
would expect the iteration order to be consistent, but this seems to be the
key.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.