[SOLVED] Apps freezing for several seconds in stretch

[Faroe]

Thunar is well-know for freeze issues.

Oh, indeed, I'd had my share of headaches caused by Thunar before this freezing problem appeared. I'm glad Thunar 1.6.11 doesn't crash every time I rename a file, like 1.6.10 would. Anyway, Thunar has a feature set that I'm happy with and I don't think it can be blamed for the freezing. It happens even when Thunar is not running in daemon mode in the background.

the OP said it occurs in Windows also

The symptoms in Windows 7 are much more troubling: the entire system just reboots itself without any obvious reason. However, I have no idea if those crashes are related to the freezes in Debian. In other words, they could very well be. I think they began occurring around the same time, but for all I know, it could simply be a case of Windows crashing because it is Windows.

What temperatures does the BIOS report?

The ASUS UEFI BIOS Utility reports CPU temperatures between 25°C and 27°C, which corresponds to the value of the CPU's "Physical id 0" sensor as reported by `sensors` when no resource-hungry software is running. The BIOS utility doesn't monitor the temperature of individual CPU cores.

When was the last time the thermal paste was changed?

I'm fairly sure it's never been changed. The machine was assembled less than sixteen months ago and I haven't touched the stuff.

Thanks for all the support. I'll try to assemble a list of software that suffers from the freezes and look for a pattern. I probably won't have time to come back to this until next weekend, but please let me know if there's anything else I should look into.

[Bulkley]

Freezes are very often hardware related as posters above hinted at. A failing video card can drive you nuts. Software that overloads a video card or memory can do it.

Top of the list should be software that does not agree with the assigned OS, in this case Stretch.

[pylkko]

That eliminates a software problem.

Almost, I'd say, but not entirely. Since there are settings and configurations that can cause hardware to misbehave or even brake (for example some SSD's don't tolerate SATA Active Link Power Management, or you can do firmware updates from software that would cause hardware to misbehave in many OS's etc.). Also, the problem might only appear to be the same in the two OS's but actually be distinct problems.

OP also said that drive is using SATA 3.1, so there should be no periodic system freezes from frequent TRIM (is asynchronous after 3.1).

Faroe, are you using "discard"?

After you said that you got these freezes using images, I immediately thought if this problem might be worse with say audio. But now I reread your post and see that you do say in it that multichannel audio in Audacity is really behaving in odd ways. Are the audio files that you are editing on the HDD or the SSD? Audacity, I believe, uses a temp folder on the system disk, so that would be on the SSD.

[dasein]

I may be giving a long-winded +1 to Bulkley here, I can't quite tell.

It's way too early to be making a list and checking it twice to find out which software is naughty and nice when hardware hasn't been ruled out (or anywhere close to it). If I've read the seemingly contradictory posts of the OP correctly...

1) Everything was running fine for over a year, Linux ran great. Windows ran great. All was sunshine and puppies.

2) Two different OSes are currently exhibiting problems simultaneously on the same rig. The symptoms are admittedly markedly different, which makes it impossible to determine the extent to which these issues are related. But as a purely statistical matter, Cosmic Coincidence is the least likely explanation for cross-OS borkage.

3) Interacting bugs within specific applications is also a very unlikely explanation. If it were the applications themselves, some percentage of the other folks who use those same apps would be reporting similar issues. I haven't done a Web search for similar symptoms with other distros (that's the OP's job after all), but at least as far as Debian goes, his experience seems to be unique.

4) The "stress" conditions reported by the OP don't strike me as particularly stressful for a multi-core rig with 8GB of RAM.

5) The OP doesn't say whether s/he's fully updated on Stretch, which, given the timing, is absolutely crucial. Eight weeks ago corresponds roughly to when Stretch would be at its buggiest-of-all-time.

6) Am I the only one who wants to see this OP's sources.list? Because I most certainly do.

Diagnostic/remedial steps that I haven't seen suggested...

1) Update Stretch and repro the problem

2) Repro the problem using another distro--say, Fedora (live medium is fine)

3) Repro the problem using a different set of initial "stressors" (say, 20 tabs open in Firefox)

There are still plenty of untried diagnostic steps (isolating RAM slots, running with only one drive active, ensuring that memtest is updated to the latest version). But they are all less likely to be informative than these initial steps.

[Faroe]

Faroe, are you using "discard"?

No, I'm not. I assume you're referring to the mount option, which doesn't appear in my /etc/fstab. Also `findmnt -O discard` gives no output but `findmnt -O nodiscard` does. Is that the correct way to check this?

But now I reread your post and see that you do say in it that multichannel audio in Audacity is really behaving in odd ways. Are the audio files that you are editing on the HDD or the SSD?

The files are on the HDD. I should point out that the out-of-sync error I described happens quite rarely. More often Audacity freezes in the same way as Mirage, i.e. during playback (even if there are only two tracks and one is muted), it stops refreshing the window for several seconds, while the audio keeps playing as usual.

4) The "stress" conditions reported by the OP don't strike me as particularly stressful for a multi-core rig with 8GB of RAM.

I'm sorry if I haven't been very clear. The conditions I've reported are not "stress" conditions, just ordinary everyday tasks. I haven't tried to run any actual stress tests yet.

5) The OP doesn't say whether s/he's fully updated on Stretch, which, given the timing, is absolutely crucial.

I believe I am. The system automatically updates the package cache daily and notifies me if there are upgradable packages. These days there are several almost every day.

If I run `sudo apt-get update` and `sudo apt-get upgrade` manually, the latter says:

Code: Select all

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

6) Am I the only one who wants to see this OP's sources.list? Because I most certainly do.

I'm glad you asked. I wouldn't be at all surprised if the file was somehow messed up.

Code: Select all

#

# deb cdrom:[Debian GNU/Linux 8.3.0 _Jessie_ - Official amd64 xfce-CD Binary-1 20160123-19:00]/ jessie main

deb http://httpredir.debian.org/debian/ stretch main non-free contrib
deb-src http://httpredir.debian.org/debian/ stretch main non-free contrib

deb http://security.debian.org/ stretch/updates main contrib non-free
deb-src http://security.debian.org/ stretch/updates main contrib non-free

# stretch-updates, previously known as 'volatile'
deb http://httpredir.debian.org/debian/ stretch-updates main contrib non-free
deb-src http://httpredir.debian.org/debian/ stretch-updates main contrib non-free

# jessie-backports, previously on backports.debian.org
#deb http://httpredir.debian.org/debian/ jessie-backports main contrib non-free
#deb-src http://httpredir.debian.org/debian/ jessie-backports main contrib non-free

It's basically inherited from jessie. I noticed only just now that the first pair of deb/deb-src lines contains "main non-free contrib" while in the rest of them, the order of the components is "main contrib non-free". That inconsistency must have been there for years. I changed the order of the first lines to match the others and ran `sudo apt-get update` and `sudo apt-get upgrade` again, but the ordering doesn't seem to make a difference. Not that I expected any.

My /etc/apt/sources.list.d/ is empty.

2) Repro the problem using another distro--say, Fedora (live medium is fine)

I guess I should do just that, once I have a little more spare time.

Thanks for all the feedback, again.

[Faroe]

Another quick update: I ran `fstrim -v` on the SSD partition where my photos are kept and got this result:

Code: Select all

/media/photo: 22.8 GiB (24443183104 bytes) trimmed

Unfortunately, Mirage freezes just like before, if Gimp is running at the same time.

[phenest]

Are you trying to fix the problem you have on Windows? Just because they're doing different things, it doesn't mean the underlying problem is different. They are different OS's and will react in different ways.

Here's some ideas:
1. If you have another computer with similar spec, put your Debian drive in that to see if the problem still occurs.
2. If you have a spare hard drive, install Debian again (or Windows) to see if the problem still occurs.

[Faroe]

This week I did manage to investigate the Windows side a bit. I never knew about the Reliability Monitor, which looks like a pretty handy built-in tool in Windows 7. It seems that every time Windows had crashed, the exact same error message and error code was logged. I googled them and installed a hotfix that, according to some people, should cure the problem.

At the moment, it would seem that the issue in Windows is caused by the system files `csrss.exe` and `sxs.dll` misbehaving. As a matter of fact, Windows crashed twice this week before I installed the patch, which is way more frequent than before, so I'm seriously hoping the crashing would end here. Time will tell.

I haven't been able to do much about the freezes in Debian. It's unfortunate that I currently only have time to look into that during weekends. Another thing that's unfortunate is that I don't have the option of swapping either hard drive to another computer or replacing them.

[Faroe]

Sorry about another week of silence. This time I have, however, made some progress. The day after my last post something went so badly wrong with my /home partition on the HDD that Debian failed to mount it on boot. Unfortunately my root account was disabled, because I've always been happy just using `sudo`, so I couldn't access recovery mode either and the system became temporarily unusable. This was easily fixed, though, by booting another distro I had on a USB stick (Tiny Core in this case), commenting out the failing /home partition in /etc/fstab and creating a new home directory on the SSD. After that I was able to set up a root password and start the repairs.

I ran `e2fsck -cc` on the old /home partition on the HDD and as far as I could tell, no bad blocks were found, but other errors were reported during passes 1 and 5:

Code: Select all

Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 425252 was part of the orphaned inode list.  FIXED.
Inode 425420 was part of the orphaned inode list.  FIXED.
Deleted inode 425617 has zero dtime.  Fix<y>? yes
Inode 425962 was part of the orphaned inode list.  FIXED.
Inode 435657 was part of the orphaned inode list.  FIXED.
Inode 435658 was part of the orphaned inode list.  FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(2078241--2078243) -(2160238--2160257) -(2186804--2186814) -(2186928--2186935)
Fix<y>? yes
Free blocks count wrong for group #63 (18790, counted=18793).
Fix<y>? yes
Free blocks count wrong for group #65 (28821, counted=28841).
Fix<y>? yes
Free blocks count wrong for group #66 (18659, counted=18678).
Fix<y>? yes
Free blocks count wrong (1687086, counted=1687128).
Fix<y>? yes
Inode bitmap differences:  -425252 -425420 -425617 -425962 -(435657--435658)
Fix<y>? yes
Free inodes count wrong for group #52 (203, counted=207).
Fix<y>? yes
Free inodes count wrong for group #53 (6403, counted=6405).
Fix<y>? yes
Free inodes count wrong (501957, counted=501963).
Fix<y>? yes

Besides /home, there are two much larger partitions on the HDD and I've begun the process of running `e2fsck -cc` on them too. That's going to take a while. I copied the most important contents from the old /home to the new one and haven't encountered any more freezes in Mirage, Gimp or Thunar since then. I'll mark this thread as "[SOLVED]" as soon as I've finished checking the larger partitions. I think it is likely that they will also contain errors, so now I'm considering buying a new HDD. This one must be at least ten years old.

Thanks for all the help, everyone!

[smoki]

There's a problem that has been occurring in my Debian testing system for about two months now. Some apps such as Mirage, Thunar and Audacity tend to freeze occasionally. The freeze usually lasts for about 5 to 10 seconds, during which time the frozen window won't refresh or respond to mouse or keyboard input.

Sounds like an xserver bug i recently read about

https://bugs.debian.org/cgi-bin/bugrepo ... bug=855206
https://bugs.freedesktop.org/show_bug.cgi?id=100863

fixes:
https://cgit.freedesktop.org/xorg/xserv ... eab34b5a19
https://cgit.freedesktop.org/xorg/xserv ... 1e2e424e11

It only affects 1.19 X and is not in stretch package yet, so maybe you can try to patch it.

[Faroe]

Well, I can finally say the freezing problem is history. There haven't been any more issues since I moved my home directory away from the old HDD. I backed up everything I needed and bought a new HDD, which I'm going to install next. I have run `badblocks` on the two larger partitions of the old drive and while one seemed to be OK, the other contained several million bad blocks. Windows also stopped crashing when I installed the hotfix I mentioned earlier. However, I have no idea whether or not the crashes were related to the failing HDD.

Thanks again! This thing has been solved.