Charts blocks drawing while '2 Threads' is selected [...]

[johndrinkwater]

run Chart, set it up so you can see a moving animation, select '2 Threads' option. Window doesn't continue its updates, app still remains responsive though. Unselecting '2 Threads' returns Charts to normality.

[jackburton]

Can't reproduce this anymore. Maybe it's been fixed in the meantime ?

[johndrinkwater]

I still see this on rev16097 in vmware with 32bit mode, using either directwindow+drawbitmap

[jackburton]

Weird, I can reproduce it, but not consistently. Maybe it's timing related ?

[johndrinkwater]

On the first attempt to select "2 threads", it'll take a random duration to block drawing.

Any further attempts (re-enabling 2 threads) stops drawing directly after selection. Sounds deadlocky(?) on the second thread.

[stippi]

Can you guys reproduce this on R5?

[jackburton]

Chart also hangs on quit. Could be related, as uncommenting the line

"wait_for_thread(fSecondAnimationThread, &result);"

in ChartWindow.cpp (ChartWindow::~ChartWindow()) makes the app quit correctly.

I'd be interested in seeing how the app behaves in BeOS and in the testing environment. Unfortunately, I can't test on either.

[johndrinkwater]

I've been playing with this on native hardware, and cant reproduce. With testing the same revision in vmware, I can reproduce.

Maybe a gfx/vmware problem ? Is there any debug output that could help here?

[jackburton]

Replying to johndrinkwater:

The weirdest thing is that I tried to add some debug output, and then the problem doesn't show up anymore.

[jackburton]

I don't know why but I can't reproduce it anymore. I'll close this bug if no one complains.

[aldeck]

Replying to jackburton:

I can confirm that the bug appears under vmware with either haiku or r5. No problem on real hardware.

Hardcoding all instances of fSecondThreadThreshold to 0.5 in ChartWindow.cpp seems to solve the 2 threads problem. The code must be blocking itself with erroneous timing calculations. This old code is a bit too geeky/complicated for what it does IMHO :) Don't know if it's due to my modification but on one time it didn't quit properly (window closing only).

What lead me to this is the strange cpu usage display, especially when animation is off but drawing is enabled. It's maybe unrelated but i thought some timing calculation might be responsible. Maybe a clock/cpu usage issue under vmware? Or Charts is the only suspect :)

[jackburton]

Finally fixed in r22961. The calculations to distribute the load between the two threads don't seem to work correctly under vmware: they set the load for one thread to a negative number.

[nielx]

Per request of katisu.

[jackburton]

Is it reproducible in the way described in the description ? Does this happen on a SMP machine ? I cant' reproduce it here, either on vmware or real hardware (although the bug only seemed to apply on vmware).

[aldeck]

Replying to nielx:

Per request of katisu.

Any more info? Niels, what did katisu report?

[nielx]

Don't know. It was reported on the mailing list that reopening this ticket caused problems. I assumed that there was an actual reason to reopen the ticket. Cc changed to ask for more input.

[nielx]

Changing the summary to see if that makes any difference.

[nielx]

Hi Niels,

I still can't post a comment due to that "Ticket needs summary" error. Here is the info, please post it.

-- Problem still exists as reported to me by Anxiety on irc (using r23938). I was able to verify/reproduce problem using r23938 and have done so as recently as r24049 running under vmware player. Can't reproduce on native hardware (366 Celeron).

Set the animation running and select 2 threads and after a duration of time (time amount isn't consistent) the animation is frozen. After this, deselecting 2 threads restarts it, reselecting 2 threads freezes it again. I did this on a P4 HT 3GHz. First I had an old version of vmware player, but still reproducible even in the newest version of 2.02. --

Curtis (aka Katisu)

[aldeck]

Replying to nielx: Hmm, working on something else at the moment but we might need to write a test app for time functions and see if strange things happen under vmware...

[jackburton]

Replying to aldeck:

Replying to nielx: Hmm, working on something else at the moment but we might need to write a test app for time functions and see if strange things happen under vmware...

I agree. BTW I could reproduce this bug again, if I let the app run for a relative long time with "2 threads" enabled.