Hi Igor, Am 14.08.2017 um 16:34 schrieb Igor Korot:
Hi, Jens,So it really *is* closely related. The problem is in the symbol-db plugin: https://github.com/GNOME/anjuta/blob/1f196dd119b41ce70f50c028946017e1c98d4d72/plugins/symbol-db/symbol-db-engine-core.c#L1561 There is a g_warning there (in fact the one you were seeing all along), but it really is a critical error how the code is currently written, because there is no working fallback when shm is not usable. Ok, so `shm_open ("/dev/pts/anjuta [...]` fails on your system and that causes the segfault.Does this mean that the plugin needs to be fixed?
It doesn't do a good job at error recovery, as it stands shm support is required for the plugin to work.
I have 2 Gentoo system: 1. Gentoo + KDE 4 with Anjuta and GTK installed. It uses OpenRC. 2. Gentoo + GNOME 3 with Anjuta. It uses OpenRC. The interesting thing is that on the first system I don't see that crash, only on the second one.
Have you compared /etc/fstab on both systems?
Do you have any idea why? I will try to compare the USE-flags for Anjuta on both systems in the meantime.
I don't think the problem is use flag related.
And shm is mounted correctly: $ mount | grep shm tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) I would try to comment out the last line of your fstab (and remount /dev/shm or reboot).I can try to do that, but I want to hear your opinion on the question above. Thank you.
I would compare fstab files and try to remove the devtmpfs line as I already wrote. devtmpfs can be used for /dev (not /dev/shm), it is probably a typo or something. Like I wrote before udev and the init system normally take care of mounting system filesystems like /sys, /proc, /dev and even /dev/shm. Your current config first mounts shm on /dev/shm and then mounts a second filesystem over it (a devtmpfs) which looks like a mistake to me. This could cause problems with other software as well that expects shm to work. -- Mit freundlichen Grüßen Jens Mühlenhoff
Attachment:
signature.asc
Description: OpenPGP digital signature