Its a design rule kind of thing. Breaking the design rule leads to
undefined behavior. My experience is that the kind of problem described
here leads to very hard to diagnose system instability. If anything, a
"known" bug of general, intermittant instability could be associated with
this issue. If it turns out to be too hard for Artem to build what I
suggest, then a hard assert(0); should be installed. This is a 20 minute
hack. The downside is that it might snag design rule violations
unexpectedly thus causing lots of angst.
On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi,
Is there any known bug related to this issue?
Rana
> On 10/15/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> >
> > After thinking about it a while, how about the following course of
> > action:
> >
> > 1)
> > First phase is to modify hysem_wait() and any other hy.... blocking
> > functions to test if, in fact, the thread is in suspend enabled
> > mode. If
> > the thread is not, do something like a printf("WARNING: root set
> > enumeration is unstable, hytsem.cpp line #285\n"); Then do a
> > non-destructive stack unwind and printf a stack trace
> >
> > An even better idea would be to log the printf's out to a file that
can
> > later be retrieved.
> >
> > 2)
> > Second phase. Analyze the code paths that lead to the enable/disable
> > problems. Are there fundamental design flaws? Implementation flaws?
> >
> > 3)
> > Third phase. Assume the above turns up easy to fix bugs and minor
> > architectural issues. And that these issues are settled. Then commit
a
> > mod
> > to svn that will cause the system to do an assert(0); in debug mode
and
> > exit
> > w/ stack trace in release mode.
> >
> > Artem,
> > Does it make sense for you to create a patch that does the above??
> >
> >
> >
--
Weldon Washburn
Intel Middleware Products Division
