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 -~----------~----~----~----~------~----~------~--~---
