Created attachment 1991851 [details]
File: proc_pid_status

Created attachment 1991852 [details]
File: maps

Created attachment 1991853 [details]
File: limits

Created attachment 1991854 [details]
File: environ

Created attachment 1991855 [details]
File: open_fds

Created attachment 1991856 [details]
File: mountinfo

Created attachment 1991857 [details]
File: os_info

Created attachment 1991858 [details]
File: cpuinfo

Created attachment 1991859 [details]
File: core_backtrace

Created attachment 1991860 [details]
File: exploitable

Created attachment 1991861 [details]
File: dso_list

Created attachment 1991862 [details]
File: backtrace

*** Bug 2241898 has been marked as a duplicate of this bug. ***

Original description from https://bugzilla.redhat.com/show_bug.cgi?id=2241898

```
New notes do not appear on screen, sometimes applet crashes. 



Reproducible: Always

Steps to Reproduce:
1. add stricky notes to panel
2. New note
3.
Actual Results:  
Nothing. Only after pressing "new note", mouseover shows that the invisible notes are counted. 


Expected Results:  
New note on screen 

gdb attached to the Fedora 39 rpm non debug version shows:
Thread 1 "stickynotes-app" received signal SIGSEGV, Segmentation fault.
0x00007f47fed565fd in XChangeProperty () from /lib64/libX11.so.6

and mate's "unexpected close" message appears. 


New version 1.27 from git works but runs unstable, crashes when closing and opening notes.

Installing old version mate-applets-1.26.1-3.fc38.x86_64 solves the problem in the current F39 beta version.
```

mate-applets-1.26.1-3.fc38.x86_64 was build against libX11-1.8.3-2.fc38.x86_64.rpm.
A local rebuild of mate-applets against current libX11-1.8.6-1.fc38.x86_64 introduced the same issue in f38.
So chances are high that a change in libx11 causes the issue.

I tried the following:

Installed in F39 fedora:latest container, fc38, with rpm build tools. "dnf builddep" installed everything to build mate-applets, all regards for the packagers. The stickynotes in the homebrew f38 package did not work. 

The release f38 sticky notes is the only one pulling /lib64/libgtksourceview-3.so.0, not the F39 one nor the homemade F38.
"objdump -T" shows in the release F38 stickynotes-applet a lot of undefines which are NOT in the home made F38 and F39, all with "type" in their names. 

If I see it correctly, they are defined as macro in /usr/include/gtk-3.0, so disappear from the extern symbol list. 

Could it be that during the F38 rebuild, using a newer version of gtk libs, an incompatibility with GTK is introduced?



Upstream they already did something, 

  stickynotes: bump gtksourceview 4

GtkSourceBuffer provides the ability to undo or redo the change
to the note text-body.  pluma uses gtksourceview 4, so we don't
need to depend on two versions.

resulting on my system in a working but unstable version after compiling from git, but I have to look into further before sending reports. At least it produces more than invisible windows.

There is a subtile problem in the compilation stage. Key is the inclusion of libgtksourceview.

Steps:
build the F39 mate-applets rpm without cleaning the BUILD folder.
Stickynotes will not work, libgtksourceview is not in "ldd"
cd into the mate-applets BUILD directory and repeat the configure with the same line from configure.log, make stickynotes.
ldd stickynotes-applet shows libgtksourceview, cp to /usr/libexec and the software is funcyional.

I suspect some CPPFLAG, but that's beyong my competence.

Attached: Makefile as created by rpmbuild and makefile after manual configure.

Sorry, see no attach possibility,so here is diff rpm and manually repeated config:

285c285
< CC = gcc
---
> CC = x86_64-redhat-linux-gcc
287,288c287,288
< CFLAGS = -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer 
< CPP = gcc -E
---
> CFLAGS = -g -O2
> CPP = x86_64-redhat-linux-gcc -E
342c342
< LDFLAGS = -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -specs=/usr/lib/rpm/redhat/redhat-package-notes 
---
> LDFLAGS = 
361c361
< LT_SYS_LIBRARY_PATH = /usr/lib64:
---
> LT_SYS_LIBRARY_PATH = 
393c393
< PKG_CONFIG_PATH = :/usr/lib64/pkgconfig:/usr/share/pkgconfig
---
> PKG_CONFIG_PATH =

I got same results. Compiling mate-applets from git works for master (1.27) and 1.26 branch in f39 and f38 and stickynotes runs fine.
But building 1.26 or 1.27 as rpm for f38 and f39 gives the error.
I will investigate which compiler flag causes the issue in rpm building.
For the moment you can compile by hand. Use `git checkout 1.26` to switch branch
I used this options same as in rpms.
`./configure --disable-static --with-x --enable-polkit --enable-ipv6 --enable-stickynotes --libexecdir=/usr/libexec/mate-applets --with-dbus-sys=/usr/share/dbus-1/system.d --prefix=/usr` 
The 1.27 version has a weird new default gsettings key.
[rave@mother ~]$ gsettings get org.mate.stickynotes click-hide
false

Needs to be set to false otherwise you can't hide the note with a click on the icon.

Found, I think.

There is a rather weird construction defining a pointer into gsourceview, which can be done always, and in fact no real function call.
You can compile the thing leaving away libgtksourceviewe from LDFLAGS. Compilation succeeds, but you will be punished,it does not work.
You cannot leave away the includes for gtksourceview, because definition of a pointer into it. 

The culprit is in LDFLAGS:

-Wl,--as-needed 

This flag causes the lib to be not loaded if it is not needed. But not loaded means not working, so this is wrong in this special case.

I do not know yet how to fiddle this in the spec file, problably STICKYNOTES_LIBS could be a environment variable.

Learned a lot again..... 
Hope a working mate-applets in the F39 release, this is a minor change if you know how to do it.

The way it works:

diff mate-applets.spec mate-applets.spec.org 
18c18
< Release:        6%{?dist}
---
> Release:        5%{?dist}
89,92c89
< #remove as-needed flag in stickynotes Makefile to force libgtksourceview loading
< f=stickynotes/Makefile
< ftemp=$(mktemp $f.XXXXXX)
< sed '/^LDFLAGS = / s/-Wl,--as-needed//' <$f >$ftemp && mv $ftemp $f 
---
> 


I compared with a F37 VM:
Cause is update of gtksourcebuffer, where gtk_source_buffer_get_type() is replaced by a macro and the binding to the library becomes dangling.

Nice, i replaced -Wl,--as-needed with -Wl,--no-as-needed in rpm and this works for me.
`sed -i /LDFLAGS/s/--as-needed/--no-as-needed/g stickynotes/Makefile`
StickyNotes is one of the applets which i don't use for myself.
Can you please test this scratch build for f39?
https://koji.fedoraproject.org/koji/taskinfo?taskID=107125865
If it works for you i will push it to fedora.

Yes, notes appear again !

Nevertheless, it's a bit weird, C++ classes from C, I've to look into it, I have no experience with GTK.
There seems to be an introspection layer in between, so may be any function is addressed via table lookup and instance address instead of linker... Something to study. I'll try the new version too, thanks for the hind with the strange parameter.

Thanks and kind regards,

FEDORA-2023-356c4e9544 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-356c4e9544

FEDORA-2023-356c4e9544 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-356c4e9544`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-356c4e9544

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to H.Janssen from comment #23)
> Yes, notes appear again !
> 
> Nevertheless, it's a bit weird, C++ classes from C, I've to look into it, I
> have no experience with GTK.
> There seems to be an introspection layer in between, so may be any function
> is addressed via table lookup and instance address instead of linker...
> Something to study. I'll try the new version too, thanks for the hind with
> the strange parameter.
> 
> Thanks and kind regards,

If you find issues with 1.27 version please report it at upstream.
It's better to fix them now before a new MATE major release.

1.27 builds easily based on the 1.26 spec, with gtksourcesettings4

Without adapting Makefile, libgtksourcesettings4 is not loaded, so the problem persists.

The notes refuse to hide, but this already reported from a Debian user. With complete installation, there is no crash, but also no hide.

Sorry, gtksourcesettings4 should read libgtksourceview4

Which report from a debian user?
Of cource building 1.27 version as rpm gives the same problem.
This i know already.
I meant building from git and report other issues to upstream.
When build as rpm you need to add
`sed -i /LDFLAGS/s/--as-needed/--no-as-needed/g stickynotes/Makefile`
after configure part in spec file

https://github.com/mate-desktop/mate-applets/issues/650

To my opinion, this new click-hide settings is the other way around, setting it to off means that notes do hide. And it should not mean that the hide menu option disables too... If the problem persists I'll report upstream.

For the moment, I've cpuspeed, network monitor, weather and stickynotes active and all look fine in 1.27.1.

FEDORA-2023-356c4e9544 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.