|
From: Nicholas N. <n.n...@gm...> - 2009-08-11 00:26:51
|
Hi, Progress towards 3.5.0 is going well. We're down to four blockers: 200760 nor NOR othe nj...@va... ASSI darwin unhandled syscall: unix:284 200029 nor NOR Linu js...@ac... REOP valgrind isn't able to read Fedora 12 debuginfo 199338 nor NOR Linu josef.weidendorfer ASSI callgrind_annotate sorting/thresholds are broken for all but Ir 191189 wis NOR Linu js...@ac... ASSI --xml=yes should obey --gen-suppressions=all I should get to 200760 today or tomorrow. Julian has committed a fix for 200029 and is just waiting on nightly tests to confirm it. He also will soon get to 191189, which is pretty easy. Josef, will you be able to fix 199338 in the next 2 or 3 days? Julian wants to build a release candidate on Friday, so it would be good (well, mandatory, really) to have all blockers fixed by then. We also have 50 wanted3.5.0 bugs open, but it looks like only 1 or 2 of them will be done, although please feel free to work on them if you like. Nick |
|
From: Josef W. <Jos...@gm...> - 2009-08-11 16:18:38
|
On Tuesday 11 August 2009, Nicholas Nethercote wrote: > Hi, > > Progress towards 3.5.0 is going well. We're down to four blockers: > > 200760 nor NOR othe nj...@va... ASSI darwin > unhandled syscall: unix:284 > 200029 nor NOR Linu js...@ac... REOP valgrind isn't able to > read Fedora 12 debuginfo > 199338 nor NOR Linu josef.weidendorfer ASSI callgrind_annotate > sorting/thresholds are broken for all but Ir > 191189 wis NOR Linu js...@ac... ASSI --xml=yes should obey > --gen-suppressions=all > > I should get to 200760 today or tomorrow. Julian has committed a fix > for 200029 and is just waiting on nightly tests to confirm it. He > also will soon get to 191189, which is pretty easy. > > Josef, will you be able to fix 199338 in the next 2 or 3 days? Julian > wants to build a release candidate on Friday, so it would be good > (well, mandatory, really) to have all blockers fixed by then. Just fixed with a few other smaller things. However, I just saw a problem with the committed fix for 150606 (r10386). It zeros the summary counts before dumping :-( I think I'll get this right in time. I reopened 197988, as this is still valid. The easiest is to enlarge the tool's stack to a 2 MB. Or is there some adress space problem for 32bit here? It would be cool to have VG_(discard_translations) in the tool interface to get rid of an ugly hack (calling a non-public function from core) - I sent a proposed patch to Julian... Josef > We also have 50 wanted3.5.0 bugs open, but it looks like only 1 or 2 > of them will be done, although please feel free to work on them if you > like. > > Nick > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-11 23:28:02
|
On Wed, Aug 12, 2009 at 2:18 AM, Josef Weidendorfer<Jos...@gm...> wrote: > > I reopened 197988, as this is still valid. The easiest is > to enlarge the tool's stack to a 2 MB. Or is there some adress space > problem for 32bit here? I don't know. Increasing to 2MB will reduce the problem but not solve it fully -- someone somewhere someday will use Boost to generate a symbol that still overflows it. If adding a recursion limit is easy, I'd like to do that as it will definitely avoid crashes. (Ideally the symbol would be partially demangled so the user can see something useful.) Later on, if the stack size is increased then the recursion limit can also be increased, which would reduce the likelihood of it occurring. > It would be cool to have VG_(discard_translations) in the tool interface > to get rid of an ugly hack (calling a non-public function from core) - I > sent a proposed patch to Julian... Can you post the patch here? The change sounds ok to me in principle, but I think you'll have to create a new file include/pub_tool_transtab.h so I'd like to see the patch. Thanks. Nick |
|
From: Josef W. <Jos...@gm...> - 2009-08-13 22:05:05
Attachments:
dt.patch
|
On Wednesday 12 August 2009, Nicholas Nethercote wrote: > Can you post the patch here? The change sounds ok to me in principle, > but I think you'll have to create a new file > include/pub_tool_transtab.h so I'd like to see the patch. Thanks. See attachment. As there is a dependance on m_scheduler, I thought it would be better to make it part of the scheduler. The scheduler has already a dependency on transtab... Julian wanted to rethink whether there could be any further problems for discarding translations from tools. However, there is already a client request for discarding translations. So I think this should be safe. Josef |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-13 23:33:34
|
On Fri, Aug 14, 2009 at 8:02 AM, Josef Weidendorfer<Jos...@gm...> wrote: > On Wednesday 12 August 2009, Nicholas Nethercote wrote: >> Can you post the patch here? The change sounds ok to me in principle, >> but I think you'll have to create a new file >> include/pub_tool_transtab.h so I'd like to see the patch. Thanks. > > See attachment. > As there is a dependance on m_scheduler, I thought it would be better to > make it part of the scheduler. The scheduler has already a dependency on > transtab... > > Julian wanted to rethink whether there could be any further problems for > discarding translations from tools. However, there is already a client > request for discarding translations. So I think this should be safe. Three comments: - I'd still rather see it in pub_tool_transtab.h. I don't see a good reason for breaking our convention that m_foo declarations live in pub_core_foo.h/pub_tool_foo.h. - Rather than creating the new VG_(discard_all_translations), I'd prefer to just make VG_(discard_translations) visible to tools. It's more flexible, and I'm sure at some point some tool will want to only discard translations from part of the address space. - This should go in after 3.5.0, just to minimise changes at this very late stage. I figure this isn't a problem as it's just an internal clean-up and not visible to the user. N |
|
From: Josef W. <Jos...@gm...> - 2009-08-13 23:55:42
|
On Friday 14 August 2009, Nicholas Nethercote wrote: > On Fri, Aug 14, 2009 at 8:02 AM, Josef > Weidendorfer<Jos...@gm...> wrote: > > On Wednesday 12 August 2009, Nicholas Nethercote wrote: > >> Can you post the patch here? The change sounds ok to me in principle, > >> but I think you'll have to create a new file > >> include/pub_tool_transtab.h so I'd like to see the patch. Thanks. > > > > See attachment. > > As there is a dependance on m_scheduler, I thought it would be better to > > make it part of the scheduler. The scheduler has already a dependency on > > transtab... > > > > Julian wanted to rethink whether there could be any further problems for > > discarding translations from tools. However, there is already a client > > request for discarding translations. So I think this should be safe. > > Three comments: > > - I'd still rather see it in pub_tool_transtab.h. I don't see a good > reason for breaking our convention that m_foo declarations live in > pub_core_foo.h/pub_tool_foo.h. > > - Rather than creating the new VG_(discard_all_translations), I'd > prefer to just make VG_(discard_translations) visible to tools. It's > more flexible, and I'm sure at some point some tool will want to only > discard translations from part of the address space. > > - This should go in after 3.5.0, just to minimise changes at this very > late stage. I figure this isn't a problem as it's just an internal > clean-up and not visible to the user. I am fine with all of your comments. However, for making VG_(discard_translations) safe for tools, the assertion to check that we are not inside of translated code is really useful (we do not want to discard code we currently are executing). This will produce a dependency of transtab to scheduler :( Josef > > N > |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-13 23:59:55
|
On Fri, Aug 14, 2009 at 9:55 AM, Josef Weidendorfer<Jos...@gm...> wrote: > > I am fine with all of your comments. However, for making VG_(discard_translations) > safe for tools, the assertion to check that we are not inside of translated > code is really useful (we do not want to discard code we currently are executing). Do we do that check with DISCARD_TRANSLATIONS? Should we? Probably... in which case the check should be in VG_(discard_translations)? > This will produce a dependency of transtab to scheduler :( Hmm, recursive module dependencies are bad. Nick |
|
From: Josef W. <Jos...@gm...> - 2009-08-14 00:41:13
|
On Friday 14 August 2009, Nicholas Nethercote wrote: > Do we do that check with DISCARD_TRANSLATIONS? Should we? > Probably... in which case the check should be in > VG_(discard_translations)? > > > This will produce a dependency of transtab to scheduler :( > > Hmm, recursive module dependencies are bad. Or add in the comments for that function in the header file that discard_translations only should be called in places which are never called from translated code, and to be sure about this, one could add the assertion to the tool's code. Josef > > Nick > |
|
From: Julian S. <js...@ac...> - 2009-08-15 23:51:52
|
On Friday 14 August 2009, Josef Weidendorfer wrote: > On Friday 14 August 2009, Nicholas Nethercote wrote: > > On Fri, Aug 14, 2009 at 8:02 AM, Josef > > > > Weidendorfer<Jos...@gm...> wrote: > > > On Wednesday 12 August 2009, Nicholas Nethercote wrote: > > >> Can you post the patch here? The change sounds ok to me in principle, > > >> but I think you'll have to create a new file > > >> include/pub_tool_transtab.h so I'd like to see the patch. Thanks. > > > > > > See attachment. > > > As there is a dependance on m_scheduler, I thought it would be better > > > to make it part of the scheduler. The scheduler has already a > > > dependency on transtab... > > > > > > Julian wanted to rethink whether there could be any further problems > > > for discarding translations from tools. However, there is already a > > > client request for discarding translations. So I think this should be > > > safe. > > > > Three comments: > > > > - I'd still rather see it in pub_tool_transtab.h. I don't see a good > > reason for breaking our convention that m_foo declarations live in > > pub_core_foo.h/pub_tool_foo.h. > > > > - Rather than creating the new VG_(discard_all_translations), I'd > > prefer to just make VG_(discard_translations) visible to tools. It's > > more flexible, and I'm sure at some point some tool will want to only > > discard translations from part of the address space. > > > > - This should go in after 3.5.0, just to minimise changes at this very > > late stage. I figure this isn't a problem as it's just an internal > > clean-up and not visible to the user. > > I am fine with all of your comments. However, for making > VG_(discard_translations) safe for tools, the assertion to check that we > are not inside of translated code is really useful (we do not want to > discard code we currently are executing). This will produce a dependency of > transtab to scheduler :( So I am inclined to agree, it needs to go in m_scheduler, since I really want to keep the assertion but don't want yet another circular module dependency. Josef, maybe file a bug report and put the patch there, so we don't lose it? J |
|
From: Josef W. <Jos...@gm...> - 2009-08-17 08:36:25
|
On Sunday 16 August 2009, Julian Seward wrote: > On Friday 14 August 2009, Josef Weidendorfer wrote: > ... > > I am fine with all of your comments. However, for making > > VG_(discard_translations) safe for tools, the assertion to check that we > > are not inside of translated code is really useful (we do not want to > > discard code we currently are executing). This will produce a dependency of > > transtab to scheduler :( > > So I am inclined to agree, it needs to go in m_scheduler, since I really > want to keep the assertion but don't want yet another circular module > dependency. > > Josef, maybe file a bug report and put the patch there, so we don't lose it? Done. Josef > > J > |
|
From: Julian S. <js...@ac...> - 2009-08-17 11:14:13
|
> > Josef, maybe file a bug report and put the patch there, so we don't lose > > it? > > Done. Thanks. J |