Weather Routing

[ALROCHARARI]

Originally Posted by hasse_A

Raoul,

This reminds me of something I also experienced and mentioned a few days back but for me it happened while routing.



Do you need to kill the program or does it terminate by itself ?
If you need to kill it, it might be related to what I have seen.

/Hans

Hello Hans,

The program freeze. Nothing happens. I tried to move the windows but they are frozen. When I select OpenCPN or WeatherRouting or Grib window, I see appearing the message (Not responding) on the title bar and I finally receive the message asking me to wait or to cancel the program. Waiting does not help. My conclusion is that this is a separate issue from yours.

Best regards,
Raoul

[ALROCHARARI]

Hello guys,

I still have a very strange beheavior.

Working in & out with WeatherRouting and other plugins using different screens: my laptop 2560x1440 and a connection though a docking station to a 3840x1080 screen. At a certain point, the WeatherRouting icon is not responding whatever I do. Complete uninstallation of WeatherRouting with folders & tarbal file deletion is necessary with reinstallation before being able to use it again. Did not identified the exact reproductible sequence to generate it yet.

Had somebody already similar issue?

Best regards,
Raoul

[hasse_A]

Originally Posted by ALROCHARARI

Hello Hans,
My conclusion is that this is a separate issue from yours.

Raul,

Maybe not, I might not have had the patience to wait it out. Next time I will let it hang for a while and see what happens,

/Hans

[hasse_A]

Dave,

Now I got it to hang while it was "Calculating Cyclon Crossings". That's also the only box I can move. CPU at about 30%. Can not minimize OpenCPN.

/Hans

[bdbcat]

All...
My observations:
There are two classes of problem.


1. Simple GUI window focus/refresh problem on Windows.

There is some GUI problem which occurs with some control dialog positions. I have implemented a simpler dialog, not using wxSplitter, only simple box sizers. And the problem persists. It still shows the same window refresh problem when part of the dialog is off-screen. Working to narrow this down now. Looks like some trouble with wxListCtrl. Technically, OCPN is not "hung" He is getting and processing events. He is just not getting any Refresh events, so the GUI appears to be hung. You can see this, as the cursor changes to green arrow near the chart edges. This is OCPN responding to mouse input. He is not hung.
If the control dialog is fully on-screen, we do not see this GUI problem.



2. Legitimate logic errors causing a true hang, with elevated processor load, on all platforms.


If the entire extent of a proposed route is on-screen, the route completes normally. However, after completion, if the user then attempts to zoom in to large scale on any part of the route, at some scale value the system will eventually hang. It seems to be stuck in some unresolved recursive loop in the RenderOverlay() method.


Sean, this one is yours.


@Hans: How does this map with your experience?


Dave

[hasse_A]

Originally Posted by bdbcat

All...
My observations:
There are two classes of problem.


1. Simple GUI window focus/refresh problem on Windows.

There is some GUI problem which occurs with some control dialog positions. I have implemented a simpler dialog, not using wxSplitter, only simple box sizers. And the problem persists. It still shows the same window refresh problem when part of the dialog is off-screen. Working to narrow this down now. Looks like some trouble with wxListCtrl. Technically, OCPN is not "hung" He is getting and processing events. He is just not getting any Refresh events, so the GUI appears to be hung. You can see this, as the cursor changes to green arrow near the chart edges. This is OCPN responding to mouse input. He is not hung.
If the control dialog is fully on-screen, we do not see this GUI problem.



2. Legitimate logic errors causing a true hang, with elevated processor load, on all platforms.


If the entire extent of a proposed route is on-screen, the route completes normally. However, after completion, if the user then attempts to zoom in to large scale on any part of the route, at some scale value the system will eventually hang. It seems to be stuck in some unresolved recursive loop in the RenderOverlay() method.


Sean, this one is yours.


@Hans: How does this map with your experience?


Dave

Number 1) I totally agree. I see the green arrows and if you go to the bottom in this case the empty box in the left lower corner appears. I think this is the box where chart info should be displayed. Maybe you need to have charts loaded to see this.

Number 2) Yes, this is absolutely true.

/Hans

[bdbcat]

Sean, et al...
I have recorded a video (with audio commentary) demonstrating the simplest hang condition I could create. The video shows my actions in IDE to capture a stack trace at the hang point. This should get you started on looking into this bug.


https://www.dropbox.com/s/ow70ujxj73...08.44.mkv?dl=0


I also attach a screenshot of the stack trace at the hang point.


Thanks for looking
Dave

[rgleason]

Thank you Dave. routemap.cpp:1349 has

" } while(s1 != skippoints);"

and line 1273 comment

/* how many times do we cross this route going from this point to infinity,
return -1 if inconclusive */

[ALROCHARARI]

Hello guys,

Do you have same problem of "Over ground" routes?

Best regards,
Raoul

[hasse_A]

Originally Posted by ALROCHARARI

Hello guys,

Do you have same problem of "Over ground" routes?

Best regards,
Raoul

It might be a dumb question but I will ask it anyway.
Have you activated the box "Detect Land" under the configuration ?

One other dumb question.
Have you downloaded and installed the High resolution base chart ?

To answer your question: No I have not had problems with this so far.

/Hans

[seandepagnier]

Originally Posted by bdbcat

Sean, et al...
I have recorded a video (with audio commentary) demonstrating the simplest hang condition I could create. The video shows my actions in IDE to capture a stack trace at the hang point. This should get you started on looking into this bug.


https://www.dropbox.com/s/ow70ujxj73...08.44.mkv?dl=0


I also attach a screenshot of the stack trace at the hang point.


Thanks for looking
Dave

I study your report but I cannot reproduce the hang. I need to reproduce the hang to correctly fix this.

Can you post your weatherroutingconfiguration.xml, boat.xml and possibly just attach the .opencpn/plugin/weather_routing folder?

[bdbcat]

Sean...
The entire folder (except the "stock" polars):


https://www.dropbox.com/sh/6yiwdusnu...9c8kxKSMa?dl=0


Dave

[hasse_A]

I have noticed another problem where the router does not finish despite it's saying so. The effect is that you do not get a time of arrival or duration in the report. Also I think the time given in the WR-window is the time when the routing stopped and not the time of arrival.
See attachment.

[bdbcat]

Hans...
Working on the rendering hang problem now. We'll come back to this "completion" bug later. Please keep it in mind.


Thanks
Dave

[hasse_A]

Originally Posted by bdbcat

Hans...
Working on the rendering hang problem now. We'll come back to this "completion" bug later. Please keep it in mind.

Of course. One thing at a time.

In the case shown it is only with certain times of departures this happens.
I will save the complete state of the setup including gribs and polar diagram so we are sure we can reproduce the error.

/Hans