Thanks, Tobias. I will check this out. On Wed, May 27, 2009 at 10:39, Tobias Käs <[email protected]> wrote: > I've filed a new issue at > http://code.google.com/p/v8/issues/detail?id=358 > > I don't have access to any memory checker on windows but I'm able to > reproduce the crash scenario in the debugger. If there's anything else I can > do to help just ask. > > 2009/5/27 Mikhail Naganov <[email protected]> >> >> Actually, what we saw in our continuous build was an assertion failure >> due to missing tick samples (and the following crash of the test was >> intended to capture the stack of the failure). This is the problem I >> targeted in this fix. >> >> What you're talking about is a really strange thing. TickSample's >> 'samples' array isn't dynamic. And in their own turn, TickSamples are >> stored in a static array (you can find it in class Profiler from >> log.cc). So a crash you describing can be caused either by a wild >> TickSample pointer passed to TickEvent function or by a corrupted >> TickSample object. Personally, I haven't encountered anything of this >> kind so far. Can you try to involve any memory checking tools in your >> investigation? >> >> On Wed, May 27, 2009 at 00:30, Tobias Käs <[email protected]> >> wrote: >> > Thanks for the explanation, this sounds reasonable if the source of the >> > crash are missing profiler samples. For clarity can you explain what >> > crash >> > you are actually getting? I've tried to reproduce this on a windows >> > debug >> > build and I'm getting irregular crashes unrelated to the actual loop >> > timing >> > of the test. My crashes are in log.cc#1096 (Logger::TickEvent) - the >> > embedded stack vector seems to point to invalid memory. >> > >> > Sorry for the noise if this is unrelated. >> > >> > >> > 2009/5/26 Mikhail Naganov <[email protected]> >> >> >> >> Tobias, running short (less than a second) profiling sessions is >> >> impractical. This test ensures that sampler is running and its results >> >> are retrieved, no more. The problem is that sampler is implemented >> >> either as a signal handler or as a separate thread. I can have no >> >> guarantees from OS in what period of time it will be spawned and will >> >> start to work. So in the test I'm trying to achieve a balance between >> >> making the test to pass in a timely manner and maintaining stability. >> >> >> >> The perfect solution would be to establish explicit synchronization >> >> between the sampler and the test, but adding facilities to code only >> >> to be used in tests doesn't seem to be practical. >> >> >> >> On Tue, May 26, 2009 at 22:46, <[email protected]> wrote: >> >> > The fix looks to me like it's just hiding the problem, not fixing it. >> >> > The crashes may be caused by an edge case which gets triggered if the >> >> > time span is short. >> >> > >> >> > http://codereview.chromium.org/115772 >> >> > >> > >> > > >
--~--~---------~--~----~------------~-------~--~----~ v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev -~----------~----~----~----~------~----~------~--~---
