You are not logged in.
Pages: 1
Hello:
Running on an up to date Devuan Beowulf:
groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$
I have come across a problem in thunar which consists of it crashing when I want to "drag and drop" a file from a folder into another folder.
thunar crashes the instant I move the mouse to "drag" the file I am "holding" by depressing the mouse's right button.
This happens independently of the location/destination of the file.
ie: within folders in the same drive or from/to to another mounted drive.
"Drag and Drop" is not something I do very often so I cannot say when this started to happen, but it may have started after upgrade to 3.1.0.
/var/log/kern.log, /var/log/syslog and dmesg have a line (obviously the same one) for each time this happens:
Mar 13 14:13:38 devuan kernel: [25529.814724] traps: Thunar[3927] trap int3 ip:7f5fcdb41c75 sp:7ffd5aa20300 error:0 in libglib-2.0.so.0.5800.3[7f5fcdb09000+7e000]
And ~/$ .xsession-errors has this:
(Thunar:3927): Gdk-ERROR **: 14:13:38.788: The program 'Thunar' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 8499 error_code 3 request_code 141 (Composite) minor_code 8)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Any ideas as to to fix this?
Thanks in advance,
A.
Last edited by Altoid (2021-03-13 17:50:11)
Offline
Hello:
An update on this post.
I have come across a problem in thunar which consists of it crashing ...
While testing, I realised that this problem only happens only inside thunar, in or from a thunar window.
I can "drag and drop" a file or folder from the desktop into a thunar window and everything will work as intended.
ie: thunar does not crash nor does the desktop freeze.
I cross-posted it to the Xfce forum, also with no luck.
So then I posted the problem to gitlab.xfce.org.
See: https://gitlab.xfce.org/xfce/thunar/-/i … note_27697
One comment was this:
Note that, the bug reporter is using outdated versions of the various involved components (thunar, GTK, X and xfwm4), so it may be the case that this issue was fixed long ago.
thunar, GTK, X and xfwm4 are all linked by being in the same bag so to speak. ie: Xfce 4.12.
So I don't really get the idea behind this comment.
I probably won't be upgrading to Xfce 4.16.
See https://www.xfce.org/about/news/?post=1608595200 and this thread https://forum.xfce.org/viewtopic.php?id=13689.
Acting on a question in the bug report, I turned off compositing in Applications > Settings > Window Manager Tweaks > Compositor and unchecked "Enable display compositing".
The problem went away.
Then I decided to try with another file manager to see if the "drag and drop" problem was common to any other one.
My first choice was PCManFM as it was the lightest download.
I did it without uninstalling thunar and with compositing enabled.
The experiment was a 100% success, the "drag and drop" problem did not happen with PCManFM.
At first I thought that installing PCManFM may have fixed something as the install also downloaded these files:
libfm4:amd64 - libfm-modules:amd64 - libfm-extra4:amd64 - lxmenu-data:amd64 - libfm-gtk4:amd64 - gvfs-fuse:amd64
libmenu-cache-bin:amd64 - libfm-data:amd64 - pcmanfm:amd64 - libmenu-cache3:amd64 - libfm-gtk-data:amd64
But no: running Thunar again with compositing enabled still has the "drag and drop" problem.
That's about it.
I will be keeping PCManFM and seriously considering leaving Xfce and if not, least pinning it at 4.12.
Cheers,
A.
Last edited by Altoid (2021-03-17 12:57:25)
Offline
Perhaps play with mouse settings and see if this helps?
Offline
Hello:
... play with mouse settings and see if this helps?
Does not make any difference, it is not a mouse problem.
Given my observations, I have concluded that this is a problem with thunar and how it interacts with compositing.
Maybe it is related to how Xfce intruments compositing?
The maintainers at gitlab.xfce.org first made a reference to my using " ... outdated versions of the various involved components (Thunar, GTK, X and xfwm4) ..."
They have told me me that no one else has reported it and had not been able to reproduce it.
On their suggestion, I also tried to get a backtrace but the gdb utility did not produce a stack on thread apply all bt full or bt.
Alternatively, running it as root completely froze my desktop and did not produce a stack either.
So there's evidently something wrong there.
So I will just get rid of thunar and stay with PCManFM.
It seems to work quite well and most importantly, does not crash under the same conditions thunar does.
Best,
A.
Last edited by Altoid (2021-03-17 20:57:44)
Offline
Hello:
... using xfwm4 compositing from the tweaks dialog ...
Yes.
It's all xfwm4: thunar, compositing, etc.
Unfortunately, removing thunar is a messy affaire.
It is so ingrained into Xfce and the desktop that without it, the icons on my desktop would not open and the system complained about org.xfce.filemanager not being found.
The workarounds I found on the web did not work and I had to install it again, bringing along thunar-volman.
It's a real pain in the ass and yet another reason to consider dumping Xfce.
Thanks for your input.
A.
Offline
Ok so if the xfce4 compositor is the issue, maybe see what happens using compton compositor. Disable xfwm4 compositing in window tweaks then...
# apt install compton
then in a terminal
compton -b
then do drag and drop in thunar and see what messages if any print in the terminal.
control -c to cancel compton.
Last edited by dice (2021-03-18 12:59:28)
Offline
Hello:
... if the xfce4 compositor is the issue, maybe see what happens using compton ...
The issue is evidently xfce4 inter-component related.
And from what I have seen with how the 4.16 version is coming along, things won't get better.
It's a pity but that's how it is rolling these days.
So I won't insist with Thunar unless PCManFM ends up not being up to par and have to try something else.
I already have a parallel Beowulf installation that I am attempting to build up as what at one time #! Linux was, I really liked it.
Thanks a lot for your input.
Best,
A.
Offline
Ive been using cinnamon desktop lately just to see how it goes and its not bad, uses around a 700mb on startup but it is put to good use, very snappy for a bloated desktop environment. I think im over computing though and getting bored with it. If you dont mind the extra ram usage and a bit of gnome i suggest cinnamon as desktop env, Ive only got 4G of ram and i hardly use all of it unless im doing something ram intensive which i havent done for a long time. Anyhow, no such isses with drag and drop using nemo.
Last edited by dice (2021-03-19 11:13:33)
Offline
Hello:
... using cinnamon desktop ...
I looked at Gnome under Debian just once years ago in my first attempt at Linux.
Not really what I was wanting to see.
A couple of years later I used Cinammon and then Mate in a few other distributions.
I did not like them too much, really didn't see any need for so much bling and flash.
You have MS for that type of thing.
#! Linux with it's customised Openbox WM was great but that distrubution went south in 2015.
Then systemd crept into everything around me but then found Devuan which came with with Xfce.
As time goes by and I use it more (no more office IT work+MS stuff to deal with), I find Xfce more and more annoying.
The fact that at v4.12 Xfce has not been able to get icon behaviour working properly is really annoying and if 4.16 ends up being what it says it will be ...
... dont mind the extra ram usage and a bit of gnome ...
But I do mind.
Both in principle and in practice.
[rant]
Things are what they are in IT because the concept of lean and mean has long been abandoned.
Intelligent/clean coding seems to have become a thing of the past.
If those chaps who write those absolutely incredibly efficient viruses in 8 or 10 lines of code used their skills to write a Linux desktop, Linux would be the king of the desktop PCs today.
Yes, one highly adaptable and configurable desktop, instead of the absurd number of bloated DE we have today.
There's far too much crap (and time/effort spent) in the name of a mis-interpreted freedom within an ecosystem where everyone and his dog wants to be a prima donna.
[/rant]
Right.
I will now quietly step off my box and go have my second morning espresso.
Maybe then I'll feel better. 8^7
Thanks for your input.
Best,
A.
Offline
Hello:
The issue is evidently xfce4 inter-component related.
Apparently (?) the problem has been fixed/worked around.
https://gitlab.gnome.org/GNOME/gtk/-/issues/3715
From what I think I understand, a patch has been written up so that the affected applications don't crash.
ie: the root of the problem (in xfce4?) will remain where it is till the next time someone reports something else.
The Devuan Beowulf repository has libgtk-3-0 3.24.5-1 and the Chimaera repository has 3.24.24-3.
The patch is in 3.24.29.
How can I go about checking to see if 3.24.29 fixes the problem?
Thanks in advance,
A.
Offline
v3.24.29 seems to be available in Debian's experimental repositories:
Brianna Ghey — Rest In Power
Offline
Hello:
v3.24.29 seems to be available in Debian's experimental repositories:
http://deb.debian.org/debian/pool/main/ … _amd64.deb
Thanks for the heads up. 8^)
So ...
Download the .deb and install with dpkg -i libgtk-3-0_3.24.29-1_amd64.deb?
Or is there a better, more fool-proof way?
Thanks in advance,
A.
Offline
That would be the way I would try it. It is technically "safe" to add the experimental repositories directly and without pinning because packages from there have a default pin value of 1 (one) so you could do that instead if you wanted but be sure to play close attention to the suggested course of action before accepting.
Brianna Ghey — Rest In Power
Offline
Hello:
... the way I would try it.
... technically "safe" to add the experimental repositories directly ...
Hmm ...
There must be a solid reason for experimental. 8^D
I remembered looking up this once.
It seems that dpkg -i package_file.deb does not take care of dependencies prooperly or at all.
Which apt install ./package_file.deb does:
groucho@devuan:~/Downloads$ sudo apt install ./libgtk-3-0_3.24.29-1_amd64.deb
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libgtk-3-0' instead of './libgtk-3-0_3.24.29-1_amd64.deb'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
libgtk-3-0 : Depends: libatk1.0-0 (>= 2.35.1) but 2.30.0-2 is to be installed
Depends: libc6 (>= 2.29) but 2.28-10 is to be installed
Depends: libgdk-pixbuf-2.0-0 (>= 2.40.0) but it is not installable
Depends: libglib2.0-0 (>= 2.59.0) but 2.58.3-2+deb10u2 is to be installed
Depends: libjson-glib-1.0-0 (>= 1.5.2) but 1.4.4-2 is to be installed
Depends: libpango-1.0-0 (>= 1.45.5) but 1.42.4-8~deb10u1 is to be installed
Depends: libxcomposite1 (>= 1:0.4.5) but 1:0.4.4-2 is to be installed
Depends: libgtk-3-common (>= 3.24.29-1) but 3.24.5-1 is to be installed
E: Unable to correct problems, you have held broken packages.
groucho@devuan:~/Downloads$
... if you wanted but be sure to play close attention to the suggested course of action before accepting.
My guess is that I'd have to fetch all these unmet dependencies from experimental also.
But I'd rather not dive into dependency hell and be sure.
I think I'll live with the occasional crash and wait.
In any case I'll eventually be ditching Xfce4.
I don't like where it is going, so I may try LXDE, à la Knoppix Live or a #! solution.
Thanks for your input.
Best,
A.
Offline
The missing dependencies are mostly from sid/ceres rather than experimental. It looks like that .deb cannot be installed in a beowulf system without breaking it.
You could try backporting it but you would probably have to also backport several other packages and then keep them updated manually afterwards. Probably not worth the bother.
Brianna Ghey — Rest In Power
Offline
Hello:
... dependencies are mostly from sid/ceres rather than experimental.
... that .deb cannot be installed in a beowulf system without breaking it.
Enough for me not to consider attempting it.
... could try backporting it ...
... not worth the bother.
I agree.
Thanks for your input.
A.
Offline
Pages: 1