Open extremelydangerous opened 5 years ago
Seems distro-specific. Do you have a stack trace or anything else? I cannot reproduce on my side...
I can confirm this happens if you install FreeBSD i386 on an amd64 machine.
Cannot reproduce on Debian Unstable. Maybe this is BSD-only as we have two confirming this on BSD's and nobody on Linux?
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.
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.
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