Profiling segfaults

[pbaur]

Turning on profiling segfaults on the next executing any function:

pb@mango:~/dev/QNial7/BuildNial/build> gdb ./nial
GNU gdb (GDB; openSUSE Leap 15.2) 10.1
...
This GDB was configured as "x86_64-suse-linux".
Reading symbols from ./nial...
(gdb) r -i
Starting program: /home/pb/dev/QNial7/BuildNial/build/nial -i
...
Q'Nial V7.0 Open Source Edition Intel x86 64bit Linux Jan 11 2021
Copyright (c) NIAL Systems Limited
clear workspace created
     foo is op n { n }
     foo 9
9
     setprofile l
o
     foo 9

Program received signal SIGSEGV, Segmentation fault.
profile_ops_start (entr=entr@entry=55128) at /home/pb/dev/QNial7/BuildNial/src/profile.c:1097
1097      childnode = current_node->children[find_child(current_node, entr)];

Happens on all platforms I use; Linux 64bit, MacOS 64bit, Windows 64bit, with the pre-built binaries as well as rebuilt from source (except I didn't rebuild for Windows).

[gibbonsja]

Thanks for submitting the report and the additional gdb detail.

I will look at this in the next couple of days.

I am interested in how Nial is being used. May I ask how you are using Nial.

John Gibbons

[pbaur]

My apologies for the late answer, I thought I had a watch on the repo (but apparently didn't). Thank you for looking into it, much appreciated! Eventually I'll get the time to get acquainted with the internals of the implementation (it looks very nicely written and documented :), but right now I'm swamped, unfortunately.

As for my use of Nial:

(1) for being targeted at array processing, I use it for genomic sample processing: usually simple vectors (or collections of, but in general no complex structures), but really huge vectors. Nial is a stunningly beautiful language and provides a comfortable environment to work with, yet the performance of having the array processing primitives in the VM.

(2) due to being beautiful, consistent, elegant---and lots of other very welcome nice characteristics---I am also considering as a general-purpose language.

[gibbonsja]

Seqfault problem has been examined and consists of two parts

1. A code sequence problem that has been fixed and pushed to the repository. This caused the segfault.
2. Code is not fully converted to 64 bit model. This will be fixed soon but may cause problems in the interim with workspaces over 16 Gigabytes. New binaries will be put on the repository when this is completed.

[pbaur]

Awesome, thank you lots for fixing this issue and also pointing out the 16GB pitfall! It will help me get a better feeling for the language, the "do", "avoid", and "don't" aspects that are not always obvious unless you know the implementation details.