New versions (0.9.99.56/7) crashes

[mlopezgva]

Hello!

v.0.9.99.[67] throws a core-dump.
v0.9.99.5 works fine

I've tried the x86 and the x86_64 zip releases.

System:

 Distro: Linux Mint 21.3 Virginia
   base: Ubuntu 22.04 jammy
 Kernel: 5.15.0-126-generic x86_64
Desktop: Cinnamon 6.0.4
        tk: GTK 3.24.33
        wm: muffin vt: 7
        dm: LightDM 1.30.0

Machine:

Type: Laptop System: ASUSTeK product: ZenBook UX431DA_UM431DA v: 1.0
Mobo: ASUSTeK model: UX431DA v: 1.0
UEFI: American Megatrends
   v: UX431DA.300
date: 07/16/2019

Error in kern.log:

traps: vtm[3385393] trap divide error ip:7fa6978aebb9 sp:7ffcc7f80e00 error:0 in libc.so.6[7fa697761000+195000]

Execution output.

If you need anything else, just ask.

❯ vtm
  os: Terminal type: xterm-256color
  os: Color mode: xterm truecolor
  os: Mouse mode: VT-style
[1]    3385995 floating point exception (core dumped)  vtm

I've tried with three terminals (qterminal, wezterm and kitty), just in case...

[o-sdn-o]

Thanks, I'll try to reproduce it and fix it.

[o-sdn-o]

I can't reproduce this issue on a clean install of Linux Mint 21.3. Could you please provide your vtm settings.xml or $VTM_CONFIG envvar value if any of them are used?

• ~/.config/vtm/settings.xml
• /etc/vtm/settings.xml

[mlopezgva]

I can't reproduce this issue on a clean install of Linux Mint 21.3. Could you please provide your vtm settings.xml or $VTM_CONFIG envvar value if any of them are used?

• ~/.config/vtm/settings.xml
• /etc/vtm/settings.xml

I have none of these. Which I suppose means it is using the defaults. :-)
I'll try the new v.58 in a few (a couple of) hours.

[o-sdn-o]

There are also cases like this:

https://randomascii.wordpress.com/2012/04/21/exceptional-floating-point/

There have been various instances in the past (printer drivers from a manufacturer who shall not be named) that would enable floating-point exceptions and leave them enabled, meaning that some perfectly legitimate software would start crashing after calling into third-party code (such as after printing). Having somebody’s hapless code crash after calling a function in your code is a horrible experience, so be particularly careful if your code may end up injected into other processes. In that situation you definitely need to not leave floating-point exceptions enabled when you return, and you may need to be tolerant of being called with floating-point exceptions enabled.

[mlopezgva]

Tried v0.9.99.61 and it still crashes. :-(

[o-sdn-o]

Well, I will investigate further.

[eMPee584]

Well compiling from source produces a working binary..
Also, a tarball inside a ZIP is kind of a strange artifact format 😆

[o-sdn-o]

It looks like FPU errors are a consequence of static linking.

[o-sdn-o]

a tarball inside a ZIP is kind of a strange artifact format

Artifacts are created using Github Actions (tar is created using 7zip, and the final zip is done by Github.):

vtm/.github/workflows/build.yml

Lines 102 to 104 in 3223a4e

	- name: Pack (POSIX)
	if: matrix.os != 'windows-latest'
	run: 7z a -ttar vtm_${{ matrix.platform }}_${{ matrix.arch }}.tar ${{ steps.strings.outputs.bin }}/vtm

[o-sdn-o]

I think I found the cause of the crash. The problems started after c8e011e. There, dynamic libc.so calls are apparently used. This was a stub for future X11 support. I can remove this code and everything will work (this is my assumption). In the future, I will have to come up with something to workaround this and to support X11 with static linking.