From kde-bugs-dist Mon Feb 28 23:12:22 2011 From: Howard Chu Date: Mon, 28 Feb 2011 23:12:22 +0000 To: kde-bugs-dist Subject: [Bug 79362] Debug info is lost for .so files when they are dlclose'd Message-Id: <20110228231222.0410A80909 () immanuel ! kde ! org> X-MARC-Message: https://marc.info/?l=kde-bugs-dist&m=129893464126024 https://bugs.kde.org/show_bug.cgi?id=79362 --- Comment #26 from Howard Chu 2011-03-01 00:12:16 --- (In reply to comment #25) > OOOOoooohhhh. I totally misunderstood where you were going in the previous > post. This seems to get the job done with very little new code. Unfortunately I > suspect it has some nasty side effects. In particular, there are some places > that print out stacktraces without going through pp_ExeContext. So those would > end up using a stale value in VG_(ec_curr_ecu). I was wondering about that. In those cases, we have no idea what ecu applies, so it's hard to say that any particular value is more right or wrong than any other. I was thinking of zeroing VG_(ec_curr_ecu) before pp_ExeContext returns, and then we can skip the ecu checks in debuginfo when VG_(ec_curr_ecu) is zero. But regardless, the odds of returning a wrong value are the same. > Also, is it a true statement that only 1 thread is ever printing stack traces > at a time? I don't have a good feel for all the guarantees of valgrind yet. The > case I am thinking about is two threads doing something bad (e.g. accessing off > the end of a malloc'ed array) at the same time. They would both print a current > stack trace (i.e. where the bad access happened) and a past stack trace (i.e. > where the allocation of said array occurred). valgrind itself is single-threaded, no matter how many threads it simulates on the target. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.