I had curious behavior with this file
In debug mode it crashed on "delete m_pTimelineSet"
Correcting this permit to work but still crashed in release mode with the same sources !
A the end, only deactivating BMS data allowed it working in any case
There is something wrong in BMS treatment, but I didn't find it
Jean Pierre
I reproduced the problem. I needed a slight change in how it allocates the BMSbits, so I don't think it will crash anymore.
There are some issues with how it renders the numbers and arrows in orientations besides north up, a completely different problem.
In the area around Gothenburg in Sweden, ~ 57 40 N,11 45 E, O is struggling a bit when transiting from a CM93 C scale chart to a E scale chart.
First the C view:
And the E view:
In both cases I'm using Display Category "All", CM 93 detail level "0" and "Reduced detail at small scale" is ticked.
Switching from C to E charts takes quite some time the first time in each session.
The E chart view is not very helpful with a cluttered display.
Increasing the scale to ~1:30.000 makes things much better.
This is on Linux. Comparing with Win 3.3.16.06 I can't see the same problem.
I get something very similar with W8.1 ( see shot test1 attached )
But not only at this position, but generally in all this region ( see second shot test2)
I get the same with my second device and Vista ( see third shot test 3)
At these positions, when zooming and panning very frequently the system hangs and sometime crashes ( see shot hang)
273. Improve cm93 chart scale selection logic to preclude overzoom where possible.
At the location you indicate, here is what happens:
1. Showing C" scale, OK.
2. Zoom in.
3. Calculate overzoom factor on C scale. Overzoom is too high, so we want to switch to a larger scale chart. Try to find "D" chart.
4. However, there is no "D" scale cm93 chart here,
5. So switch to the "E" scale chart.
6. However, the "E" scale chart is very "under-zoomed", so takes a long time to render, and is very cluttered.
This is maybe a pathological case/location, where the cm93 chart set jumps from "C" to "E", without a "D" step.
But I suspect it may actually be a very common situation.
So I suppose that I need to modify the logic such that "small Overzoom" is preferable to "large Underzoom".
jp. I would like to see some more info/dump report on a crash or hang in this condition.
I went sailing over the weekend and noticed several hangups after a couple of hours.
I only used dashboard + AIS. No routes, now waypoints, no grib, etc.
I ran O with OpenGL off, as it needs less current (0.3 Amps) w/o OpenGL.
On any hangup, O ran unattendely inside the boat, so there was no user interaction.
It looks like O freezes completely, there's no more data visible in dahboard and also the screen's not refreshed anymore (if you move the main window of O, the background turns black). As if it was in an infinite loop ...
But it doesn't draw much CPU, 2-4 % only.
On Saturday, I had to kill it via task manager (and the wole track was lost) , on Sunday I was able to stop O as normal. The track was saved then, but had stopped some distance away from the current position (probably when it had hung up).
No error messages in the log file at all.
Codebase was 15.07., compiled in release mode. I'm using Win7, 64 bit on my Fujitsu Esprimo Mobile laptop (As usual), with CM93.2 charts.
I noticed one more thing, only with OpenGL on (!). See screenshot with markup please. Those grey squares disappear as soon as you turn off OpenGL.
Uploading several waypoint via standard NMEA port to GarminGPS 152 seems to work now.
Back to the crash we discussed recently you couldn't reproduce
Conditions : touch screen activated
I tested with new compilation on my W8.1 :
in debug mode : no dump, the system hang definitely and I have to cancel debugger
in release mode : no surprise, the background (the map) become black, the other windows if any stay visible. If a windows is open, (for example the WP properties, I can move it. As if O would not be crashed but lost somewhere in a endless loop
And off course no proposal of a crash report
Could you try this process :
- touch screen ON
- have a route not too far from a track
- scale around 50000
- drag a route point to very near the track (in it's selection area or more probably in a track point selection area)
Jean Pierre,
the event system of OpenCPN should be reworked.
Instead of using static event tables the dynamically connection with wxEvtHandler::Bind<>() is more flexible and may avoid unexpected crashes.
Gerhard
Cagney et JP...
jp. I would like to see some more info/dump report on a crash or hang in this condition.
Thanks
Dave
It happens and easily reproducible in a zone inside about
50N 60N - 4E- 7E (west cost of Norway)
when zooming, we can see many obstruction or rocks marks (*)
Choose an area particularly clustered by these marks and zoom abruptly on it
Generally the system hang and sometime, the background (chart ) become black. That what I called crash, but in fact it's not really crashed. If I wait, after a while, I get the zoomed chart
I tried in debug mode and it's the same, without black background but even longer as debug mode is very-very slow on this low powered machine
Also, if you can reproduce the problem in VS2010 Debug mode, it might be useful to break into the running program (Debug->Break All) and look at the call stack.
I easily reproduce as much as I want in debug mode but as I said, O freeze and VS2010 give me absolutely nothing. When I click on "stop the debugger", VS2010 closes the O Windows and that it. No call stack
And no other option menu to click on
May be My debug enthronement is not correctly set ?