Opened 13 years ago

Closed 4 years ago

#89 closed bug (fixed)

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

Reported by: johndrinkwater Owned by: jackburton
Priority: normal Milestone: R1
Component: Applications/Chart Version: R1/Development
Keywords: Cc: katisu
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by jackburton)

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.

Change History (33)

comment:1 Changed 13 years ago by jackburton

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

comment:2 Changed 13 years ago by johndrinkwater

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

comment:3 Changed 13 years ago by jackburton

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

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by johndrinkwater

Owner: changed from sikosis to jackburton

comment:6 Changed 13 years ago by jackburton

Status: newassigned

comment:7 Changed 13 years ago by stippi

Can you guys reproduce this on R5?

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by 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?

comment:10 Changed 13 years ago by johndrinkwater

Summary: Charts blocks drawing while ?2 Threads? is selectedCharts blocks drawing while '2 Threads' is selected

comment:11 Changed 13 years ago by diver

Cc: diver added

comment:12 Changed 13 years ago by korli

bug_group: developers

comment:13 in reply to:  10 Changed 13 years ago by jackburton

Description: modified (diff)
Platform: All

Replying to johndrinkwater:

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

comment:14 Changed 12 years ago by jackburton

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

comment:15 Changed 12 years ago by jackburton

Resolution: fixed
Status: assignedclosed

comment:16 Changed 12 years ago by jackburton

Resolution: fixed
Status: closedreopened

comment:17 in reply to:  16 Changed 12 years ago by aldeck

Replying to jackburton:

I can confirm that the bug appears under vmware with either haiku or hrev5. 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 :)

comment:18 Changed 11 years ago by jackburton

Resolution: fixed
Status: reopenedclosed

Finally fixed in hrev22961. 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.

comment:19 Changed 11 years ago by nielx

Resolution: fixed
Status: closedreopened

Per request of katisu.

comment:20 Changed 11 years ago by 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).

comment:21 in reply to:  19 Changed 11 years ago by aldeck

Replying to nielx:

Per request of katisu.

Any more info? Niels, what did katisu report?

comment:22 Changed 11 years ago by nielx

Cc: katisu added

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.

comment:23 Changed 11 years ago by nielx

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

Changing the summary to see if that makes any difference.

comment:24 Changed 11 years ago by 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 hrev23938). I was able to verify/reproduce problem using hrev23938 and have done so as recently as hrev24049 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)

comment:25 in reply to:  24 ; Changed 11 years ago by 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...

comment:26 in reply to:  25 Changed 11 years ago by 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.

comment:27 Changed 8 years ago by richienyhus

Version: R1/alpha2

Is this still valid ?

comment:28 Changed 8 years ago by humdinger

I just installed VirtualBox and tried hrev39180. The ticket is still valid. Checking "2 threads" will stop the drawing, cpu usage goes back to idle(?). Unchecking "2 threads" starts the drawing again. There's no delay for me. This is on a Core2Duo, though VB refuses to start with more than one CPU, so there's only one core according to Pulse.

In general, Haiku uses an awful lot of CPU when just moving the mouse in VB... Thank gods my virtual times are over! :)

comment:29 Changed 7 years ago by diver

Cc: diver removed
Component: ApplicationsApplications/Chart
Version: R1/alpha2R1/Development

Still here in hrev44622.

comment:30 Changed 5 years ago by pulkomandy

I can't reproduce this on rela hardware. Is it still a problem?

comment:31 Changed 5 years ago by diver

Yes, drawing still blocks in hrev48022.

comment:32 Changed 5 years ago by jackburton

I'd lower the priority, though, since it only happens on certain configurations, and it's not exactly a critical component.

comment:33 Changed 4 years ago by stpere

Resolution: fixed
Status: reopenedclosed

I put a workaround in hrev49353. Basically, you could have a situation like this : bigtime_t before = system_time(); SomeCalculation(); SomeOtherCalculation(); bigtime_t after = system_time();

and you could have some cases where after - before < 1 (either 0 or negative). When used in the division right after, you would have a division by 0 (NaN) that would break the logic further down and poison the animation as the ratio is calculated from the ratio calculated in the previous cycle.. NaN * NaN, etc..

So, I made sure the after-before was at least 1 and it seems to work ok. Since the time calculation was more or less only there to calculate a load ratio, it doesn't have to be extra accurate.

Note: See TracTickets for help on using tickets.