#121 viking often crashes after a couple of minutes

[Fabian Affolter]

After the package update in Fedora I get crashes.

$ rpm -q viking
viking-1.6-1.fc21.x86_64

:::bash
$ viking

(viking:29598): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_has_alpha: assertion     'GDK_IS_PIXBUF (pixbuf)' failed

(viking:29598): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viking:29598): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viking:29598): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed

(viking:29598): GdkPixbuf-CRITICAL **: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
Segmentation fault (core dumped)

If you need more details please let me know.

[Rob Norris]

Yes I need more details please. A full stack trace of all threads would be very useful.

I've previously encountered it crashing in a similar manner just the once, I haven't been able to repeat it or seen it again.

Since you seem to be able to repeat it then there's hope of understanding the problem and hence fixing it.

[Alessandro Meliota]

It happens to me very often,, especially when zooming and panning, so I decided to downgrade to latest stable version (1.5.2). The bug also appears on precompiled (Ubuntu 14.04 LTS) and on manually compiled versions.

Anyway, I can reproduce it. What kind of commands can I run in order to give you the requested informations?

[Rob Norris]

Run viking under the debugger and capture the stack trace including information on all threads. Since you can reproduce it with the manually compiled version, it is best to debug that version as it will have more information. (Precompiled binaries normally strip out some information to save space).

Use the command line in the directory of the program e.g. in viking/src:

gdb --args ./viking -Vd

When it crashes, enter:

bt

Which will output all the information. Copy and paste/attach all that text here please.

Thanks in advance.

You may also want to try the latest source code (https://sourceforge.net/p/viking/code/) which has a provisional fix, but I don't think this addresses the underlying problem.

[Alessandro Meliota]

Please find attached the log from gdb.
I used the 1.6 version coming from the PPA repository, with an up to date Ubuntu 14.04 ia64.

I also attached the file that for sure causes the crash. The file has been created with 1.5.2 version and works well on that.

If you need more help, please ask.

[Rob Norris]

I think I have intermittantly seen your crash happen. (Inside 'mapcache.c' - so I'm not sure this is the same failure as raised by the Original Poster (OP)).

I have had this map cache crash happen before but very rarely - and yet to fully establish repeatable circumstances, and even when it crashes under the debugger I haven't yet understood how it could get into that state - ahh the joys of C programming :(

I note in your Viking file you have two map layers that are actually the same (OSM Cycle + Mappa). I suspect this might heighten the chances of it crashing.
Best to delete one of them as both are unnecessary.

However this gives me some testing avenues to explore...

[Szymon Bigos]

Hi,

I observed such crash. It is easy to reproduce by zoom in - zoom out very fast. I sent solution to mailing list. I attache patch again here.

BR,
Szymon

[Rob Norris]

Sorry for the short reply, but thank you very much for the patch.

I hope to have time to apply it soon.

Be Seeing You - Rob.
If at first you don't succeed,
then skydiving isn't for you.

[Rob Norris]

Fix applied to master code repository.

[Alessandro Meliota]

Hi guys
Good job, I cloned the repo and did a quick test and it seems the problem disappeared.

I do not know if it related to this fix, but I found that, when panning, the behaviour is slow: I move the mouse but the map stays still and only after some time moves accordingly the pointer position. This was not present in previous stable version.
If you need more help, please ask.

Regards

EDIT: perhaps the behaviour is more evident when the mouse moves on an area with outdated tiles and there are several tracks. The map moves only when the new tiles download finishes.
I tested it with the .vik file attached to my previous message.

[Rob Norris]

A large slow down I know of is when Viking is drawing hundreds of tracks (thus in the order of hundred thousand trackpoints overall / dependent on speed of one's computer).

The performance as far as I can tell has not changed.

I don't think what you're seeing is related to fixing this bug, even so if you feel this is a significant enough problem, please create a separate bug report - but be aware that I don't have much performance metrics/analysis - so if it's non-obvious - it could be hard to fix or even a limitation of the current overall design + implementation.

Maybe one would need to bisect the code commits in order to understand which change caused the differing behaviour. But one needs to be able to reproduce issue - which I currently can't.

[Szymon Bigos]

Hi,

I think it will be good to create new bug about performance. Example of data, which causes problems, would be needed.

[Alessandro Meliota]

Ok, I'll create that.
Perhaps the problem is related to the thread synchronization, where some threads remain locked too much.
In my opinion, there should be something more: in fact, the problem that the patch try to solve can be the same that causes the slow down. The only difference is that now, with the patch applied, the program does not crash.

[Rob Norris]

Crashes when invalidating previously acquired tiles.

This race condition can most often be triggered by zooming in/out rapidly.

The fault is due to using accessing variables outside of the lock section of the memory cache.

Code submitted and now included in v1.6.1