pluma signal abort on BSD when hit ctrl-c, ctrl-z or basically ANY signal

[extremelydangerous]

Expected behaviour

when using ctrl-C to copy data on pluma, it should copy the data to scratch area in order to paste in another window. on the X screen
Rolling back to 1.19 works normal
gtk3-3.24, glib-2.56

Actual behaviour

The program signals ABORT...(signtal 6) and all the data is lost

Steps to reproduce the behaviour

start pluma 1.22 type some text, hit control-C

MATE general version

1.22

Package version

UNIX Distribution

FreeBSD-amd64, FreeBSD-i386, NetBSD-i386 NetBSD-amd64, NetBSD-arm NetBSD-arm64

Link to downstream report of your Distribution

[vkareh]

Seems distro-specific. Do you have a stack trace or anything else? I cannot reproduce on my side...

[randomMesh]

I can confirm this happens if you install FreeBSD i386 on an amd64 machine.

[lukefromdc]

Cannot reproduce on Debian Unstable. Maybe this is BSD-only as we have two confirming this on BSD's and nobody on Linux?

[randomMesh]

This has a lot to do with the i386 vs amd64 architecture. It happended to me with an installation of FreeBSD 12.1 i386 on a machine which has a 64bit CPU. The issue went away when i installed the amd64 variant of FreeBSD 12.1.

[lukefromdc]

I have the amd64 version of the Linux kernel and Debian operating system-and an AMD bulldozer proc and do not get this problem. I haven't used i386 since around 2013 when I had a netbook that required it, and whatever causes does this probably was introduced far later and well after Pluma was forked from gedit.

OK, we need more testers, to determine whether is this a BSD on i386 issue, or an issue on all i386 builds? I don't have the bandwidth (no landline) to download an installer for Debian on i386 to test that.