No image and system freeze
rasatpc opened this issue · 21 comments
- Fvwm3 version (run:
fvwm3 --version)
fvwm3 1.1.0 (released)
fvwm3 1.1.1
Fresh fvwm install does not show Fvwm logo and no wallpaper images.
https://fvwmforums.org/t/fvwm-1-1-0-no-image/4617
The system freezes when loading custom configs (Kise). FvwmPager is flickering for a few seconds. Left-click for pop-up menu is delayed. When it opens the whole system freezes.
Now I have two computers (bought one second-hand). Both show the same problem.
Version 1.1.0 on 17 March is ok.
@rastpc what is the output of fvwm --version. Seems you don't have libpng support built in. Also there is no 1.1.1, please try to understand how fvwm is versioned, there is the release 1.1.0, and the main git development branch, there is no version 1.1.1 and such a version won't exist until the release.
There shouldn't be enough differences between the main git branch and 1.1.0 to describe what you are experiencing, I'm wondering if there is an issue in the build process.
Just verified, the only difference between the 1.1.0 release and the main git branch is a few commits updating documentation only, no code has been modified. The build process might be where the issue is.
If libpng isn't being used, then the person building it would require that person to take some deliberate action.
If libpng isn't found on the system, this error occurs during the configure stage:
AC_MSG_ERROR([***
libpng not found, and --disable-png not given.
It is recommended to use libpng so that PNG icons can
be rendered by FVWM, which the default configuration
file needs, as well as other third-party programs
which generate menus, for example.
If it is critical that FVWM does not link against
libpng (perhaps due to size limitations of the
binary), then use --disable-png
***])
If someone's passed --disable-png as a result, then that would explain why icons aren't rendering, but certainly not why this ""bug"" has been reported.
@rasatpc -- since I presume you're seeing this problem first hand, and aren't merely filing this so-called bug on behalf of someone else, would you mind also attaching the config.log file?
Output of fvwm --version of heads/main.zip and latest 1.1.0 3 days ago
- fvwm3 1,1.1 (released)
- fvwm3 1.1.0 (released)
I would not have noticed this issue without purchasing the 2nd hand computer. Everything, MX linux and Fvwm with fresh new install. On my old one, works fine. On USB live MX linux + fvwm, same problem.
If libpng isn't being used
- libpng is installed
Version 1.1.0 dated 17 March 2024 is ok.
config.log
fvwm3-output.log
Thanks. Can you send me the config.log file as well?
The fvwm3-output log you attached shows fvwm either not supporting PNGs, or not finding them. What do you have set as your ImagePath?
ImagePath... this test is on a fresh fvwm install with default config.
Where is the config.log?
@rasatpc do you use a highdpi setup, I know the default-config buttons are a bit sensitive to font sizes, on my systems where I have a large monitor and I increase the Xft.dpi settings, that the buttons get to small to show the font, and in this case fvwm produces no output. I have to increase the size of the boxes for the desktop number buttons to compensate for this. The logo/image I don't think is related to this, as that should be a fixed size and not sensitive to dpi changes.
Highdpi setup, I am not using nor other additional screen settings.
I have ASUS X59F notebook and 2nd hand BenQ monitor GL2450 on Dell Optiplex 3040 PC. At first, I thought, problem with BenQ and did a quick test with debian pkg 1.0.6a.
The freeze is most likely the search of images.
Does js/right-panel-button-size help the issue? This increases the desktop change buttons, and is what I need to use on my monitors where I increase the font dpi for the buttons to be big enough to show the text.
Does js/right-panel-button-size help the issue?
Doesn't help. I will try to compare 1.1.1 with 17 March 1.1.0 to know which file causes it.
No images and system freeze are two different issues.
No image issue is caused by autogen.sh in fvwm3-1.1.0.zip. Without it, in fvwm3-1.1.0.tar.gz images appear.
The autogen.sh isssue started after v.1.0.8. If 1.0.8 was not removed before installing later versions. one will not notice the problem. v1.0.9 has the problem.
System freeze with custom-made configs, I am still checking.
Regarding the build issue you think you're seeing between 1.0.8 and 1.1.0 -- can you be more specific on which commands you're using each time to build FVWM?
Looking at the changes, I don't see anything obvious which would cause this problem. Ultimately though, if it were me looking at this, I'd use the command git bisect to track down the specific commit which has introducing the problem -- especially since you have an idea of the good and bad commits.
./autogen.sh
./configure --prefix=/usr --enable-mandoc
make
sudo make install
./autogen.sh
./configure --prefix=/usr --enable-mandoc
make
sudo make install
Well, I went through a git-bisect cycle between 1.0.8..1.1.0, and as expected there were no missing icons -- because there's been no code changes between those two versions which would cause this anyway.
@rasatpc -- can you go back through this again on your machine, and take a copy of the config.log file which is in the root of the directory you're compiling fvwm in, and when you see the failure, post the good and bad versions of config.log, so I can compare them?
I have to say though, at this point, I'm very dubious this is anything to do with different fvwm versions, and probably everything to do with the environment you're using -- but the config.log files will help determine that.
environment you're using
I am using two different computers to do the same test. There is one odd test I am also doing on both. This could be related to memory sharing.
- After install and login, there are no images. Also, nothing happened with Restart.
- In /usr/share/fvwm3/default-config/, remove images/ folder.
- Copy the same images folder from compiling folder (/home/rasat/Downloads/fvwm3-main/default-config/)
- Paste it in /usr/share/fvwm3/default-config/
- Restart and images appear.
Does the same in two computers with very different hardware spec.
So you might have tracked down the problem, but you didn't look close enough. What is different about the images/ file that was installed vs the one you manually copied over? Files missing? Permissions? Since make install should be only copying those files, identify what is different between the ones that work and the ones that don't.
File permissions in compile and system images/ folder remain the same.
A few examples:
/home/rasat/Downloads/fvwm3-main/default-config/images/ (compile folder)
drwx------ 2 rasat rasat 4096 Mar 30 14:38 bgicons
-rw-r--r-- 1 rasat rasat 5867 Mar 30 14:38 fvwm-logo-small.png
/usr/share/fvwm3/default-config/images/ (system folder)
drwx------ 2 root root 4096 Apr 3 22:59 bgicons
-rw-r--r-- 1 root root 5867 Apr 3 22:59 fvwm-logo-small.png
Persmission of system images/ folder is different from images/ folder manually copied from compile folder.
Before copying, system images/ is renamed to imagesZZ/
/usr/share/fvwm3/default-config/ (system folder)
-rw-r--r-- 1 root root 855 Apr 3 22:59 FvwmScript-DateTime
drwxr-xr-x 5 root root 4096 Apr 3 23:19 images (copied from compile folder)
drwx------ 5 root root 4096 Apr 3 22:59 imagesZZ (original by make install)
-rw-r--r-- 1 root root 149 Apr 3 22:59 stalonetrayrc
This was result of autogen.sh
Result of ./configure
./configure --prefix=/usr --enable-mandoc, without autogen.sh, generates correctly in compile and system.
drwxr-xr-x 5 root root 4096 Apr 4 00:33 images
The issue is on your environment copying the files over made the permissions 700, which means no one except root can read the files, so of course they won't work. To create these directories the install script uses mkdir -p, so try this, sudo mkdir -p /tmp/my_test_dir, then ls -ld /tmp/my_test_dir, does this dir also have 700 permissions?
I think this is partly a known issue, using mkdir here relies on the system having a sane directory mask, we could maybe add -m 755 to the mkdir command so non standard directory masks don't get in the way, @ThomasAdam what do you think about that change? modify MKDIR_P to also include -m 755, and not use the system mask? This will match the -m 644 being used with install anyways. I am also unsure how portable adding -m 755 is on systems other than debian/linux.
I really don't want to work around external factors such as different umasks -- this does come up from time-to-time -- and elsewhere in other projects. I don't want to add such workarounds here.
@rasatpc -- the question you might want to find out is why the umask settings are different, but that's just for your own edification -- so you know what to look out for in the future. :)
Thanks, I am using fvwm3-1.1.0.tar.gz with no autogen.sh. Works fine. Also, I found cause of the system freeze. It is the small Page Indicator config, recently made. I will fix it. On the forum, I informed Ivar about this.
I think we are getting old. Simple problems we don't see. I am 70 years old. :)))))
Mjaakko, on forum, found the problem. Not in autogen.sh but in the tarball.
.... default-config/images/ folder of zip and tar.gz.
fvwm3-1.1.0.zip
drwx------ 5 ......... images
fvwm3-1.1.0.tar.gz
drwxr-xr-x 5 .......... images