lockup on zoom with long tracks or ruler

I can't reproduce this in either 1.6.2 Debian 64bit nor the latest code. Neither points 1. or 2.

Can you attach a simple gpx or .vik file to demonstrate 1. please?

Alternatively if you are able to - debugging this locally may yield better information (probably need to build the program from source) - as when it locks up you should be able to interupt the process, which might show where in the code it is stuck.

Attached test1.vik - I can zoom to 2 pixelfact then it locks goig in straight from opening it.
(The track lines don't always disappear prior to lock up.)

Will set up to compile it local...

gdb shows that it gets stuck in a loop in vikviewport.c at line 1264
(called fom line 1314, 1297)
It appears there's quite some documentation on the view port clipping and the comments starting at line 1277 (of vikviewport.c)

I'm not sure what the 'optimized out' means.

'(gdb) bt
' #0 0x0457ad2 in clip_x (y2=<optimized out="">, x2=<optimized out="">, y1=<optimized out="">, x1=<optimized out="">) at vikviewport.c:1264
'#1 0x0457ad2 in a_viewport_clip_line (x1=x1@entry=0x7fd8fc, y1=y1@entry=0x7fd8f8, x2=x2@entry=0x7fd8f4, y2=y2@entry=0x7fd8f0) at vikviewport.c:1300
'#2 0x0457b9d in vik_viewport_draw_line (vvp=<optimized out="">, gc=0xd1c6d0, x1=-159548, y1=19372, x2=-159549, y2=19373) at vikviewport.c:1314
'#3 0x043644c in trw_layer_draw_track (id=<optimized out="">, track=0xc236b0, dp=0x766920 <dp>, draw_track_outline=0) at viktrwlayer.c:2267
'#4 0x00007ffff5572210 in g_hash_table_foreach () at /lib64/libglib-2.0.so.0
'#5 0x04325db in trw_layer_draw_with_highlight (l=0xbe82f0, data=0x950000, highlight=0) at viktrwlayer.c:2480
'#6 0x0459f1a in vik_aggregate_layer_draw (val=<optimized out="">, vp=0x950000) at vikaggregatelayer.c:351
'#7 0x04487c4 in vik_layers_panel_draw_all (vlp=<optimized out="">) at viklayerspanel.c:570
'#8 0x044a8f2 in draw_redraw (vw=vw@entry=0x94e0e0) at vikwindow.c:1180
'#9 0x044cff9 in draw_update (vw=0x94e0e0) at vikwindow.c:1098
'#10 0x044d396 in draw_scroll (vw=0x94e0e0, event=<optimized out="">) at vikwindow.c:1446</optimized></optimized></optimized></dp></optimized></optimized></optimized></optimized></optimized></optimized>

The default compiler settings are to apply optimization (level 02 IIR).
Thus some values are not instrumented, so the debugger can't find out what they are.

You can manually hack the src/Makefile to replace '02' with '00', but the best way is set an environment variable:
export CFLAGS='00 -g'
Then rerun ./configure and it should then remove optimization to make debugging easier.
Note the first character is the letter 'O', whereas the second is the number zero (this might not be clear depending on the font viewing this text).
You can setup your shell so the CFLAGS is always set to your preferred default, rather having to remember to apply it. (This is what I do in the ~/.bashrc file)

The latest code (rather than v1.6.2) has changed the while loop method into a fixed calculation.
See: https://sourceforge.net/p/viking/code/ci/1f1cedf7ed176f955d8835112a873d87988ce458/

You can get the latest code using git, or use the Code->'Download Snapshot' in Sourceforge.
Thus is should now never get stuck - not that understand how it got stuck previously. I don't claim to fully understand the new method either though...

Hopefully this issue has already been solved.

Recompiled with '-O0 -g' and got values. The open loop method (v1.6.2) was never going to converge with the values I saw.
I tried compiliing the latest code snapshot straight out and had compiler errors.
I copied the vikviewport.? from the snapshot and it had unresolved symbols. So I just edited in the change for that "Clip improvements, previous code was not working correct for long distances." issue link you gave for changes to vikviewport.c and compiled an it works a lot better.
Must say that a closed loop calculation is much better than an open loop iteration (with poor limit setting) for sure.
I am still having some trouble with a noticable longer pause on consequitively tighter zooms then eventually receiving multiple stderr 'Ignoring Xlib error: error code 9 request code 130' and then a core dump. But I have a rather large number of very long tracks... and don't see an easy way out of it withouth doing some really good testing to ignore drawing it if the track isn't anywhere near the viewport in the first place. (I'll delve into testing my own local code changes when I get some time to look into it, having a vested interest.)
Not really that happy (but I can get in a couple more zoom levels). So, I'd possibly consider it as (already) fixed, but where/when is the next stable version??
(Happy to continue with my local compiles...)

I had the same issue (as decribed in point 1) with 1.6.2.
In fact I changed the source to allow to zoom in much further.
With 1.7 I don't experience this problem anymore.