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<http://code.google.com/p/v8/source/browse/branches/bleeding_edge/src/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 -~----------~----~----~----~------~----~------~--~---
