[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 79362] Debug info is lost for .so files when they are dlclose'd
From:       Howard Chu <hyc () symas ! com>
Date:       2011-02-28 23:12:22
Message-ID: 20110228231222.0410A80909 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=79362





--- Comment #26 from Howard Chu <hyc symas com>  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.
[prev in list] [next in list] [prev in thread] [next in thread]