Finite-time Freeze?

Users and developers helping users with generic and technical Pale Moon issues on all operating systems.

Moderator: trava90

Forum rules
This board is for technical/general usage questions and troubleshooting for the Pale Moon browser only.
Technical issues and questions not related to the Pale Moon browser should be posted in other boards!
Please keep off-topic and general discussion out of this board, thank you!
User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Finite-time Freeze?

Unread post by moonbob69 » 2019-02-09, 09:30

Five times in the last week, PM has caused a temporary system freeze, including mouse, screen updates by Htop, and screen saver. The first three times I noticed (when unfrozen, screen saver kicks in) it was about 25-30 minutes; #4 was 24-26 minutes by kitchen timer, and #5 was 32 min 53 sec by the Htop Uptime display and also kitchen timer.

Also, the first three times were after (but not immediately) accessing problematic web sites which were either stopped or closed after causing problems. But freeze #4 only had 1 PM window with 6 well-behaved tabs: an unused "restore" tab, google, a php BB, pclinuxos.com, and 2 bugs.launchpad.net, It occurred while pointer was in the right-hand scroll area. Freeze #5 occurred a few seconds after #4 unfroze, after moving up Htop (to see if anything looked funny) and opening a new window of PM to post this message, while pointer was in the third tab area of the old PM window.

Other minimized windows were: Geany, SSH GUI (unused), Frisbee, filesystem, and Htop.
This is 32 bit PM 27.6.1 from Xenial 7.5 puppy on Toshiba Satellite with Intel Centrino Duo.

With the 2 PM windows and 7 tabs total there were 39 Palemoon PID's. Before the last freeze, Htop showed PM using 15%CPU with 268M Res memory (total 28% CPU in 5 active tasks).

With Windows machines, I had never experienced a freeze being less than permanent if it lasted more than 30 seconds.

What kind of things could cause this timing?

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-09, 12:23

Do you run a desktop environment? If so, is your machine powerful enough to run it?
Were the two windows the same istance (i.e. opened when using the same profile)?
39 Pale Moon processes is impossible unless you open it with 39 different profiles, so there's something going on about not properly terminating the process.
Also version 27 is not supported and might contribute to the problem. If possible, install version 28.

User avatar
Al6bus
Lunatic
Lunatic
Posts: 288
Joined: 2015-08-24, 14:55
Location: Lemberg

Re: Finite-time Freeze?

Unread post by Al6bus » 2019-02-09, 16:56

Off-topic:
Linux is certainly a thing of course, but I'm afraid your laptop is a little old/weak for it, and without normal hardware acceleration it’s hard to demand anything from it. I think the best solution would be to use the operating system for which the most comprehensive list of drivers is offered on the support site for your product. I can guess that this is Windows 7 32-bit.
Even a lightweight build of Windows XP with an unofficial pm build for winxp would be more preferable, than what you have now :think:
Windows 7 Pro x64 - Pale Moon x64
We hope for multiprocessing

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Finite-time Freeze?

Unread post by Walter Dnes » 2019-02-10, 00:30

moonbob69 wrote:This is 32 bit PM 27.6.1 from Xenial 7.5 puppy on Toshiba Satellite with Intel Centrino Duo.
I have an off-lease Lenovo Core2 Duo running 32-bit Slacko Puppy 5.4 and it runs PM 28.3.1 fine. Youtube https://www.youtube.com/html5 shows 4 blue checkmarks out of 6. H.264 is not supported. According to https://www.cnet.com/news/what-is-the-difference-between-intels-centrino-and-core-duo/ a Centrino Duo is a Core2 Duo, with optimizations for wireless network interoperability and longer battery life.

There have been over 20 Pale Moon releases since 27.6.1, including a bunch of bugfixes. Your problems may have already been solved by now. Try PM 28.3.1 on your current Xenial 7.5. If that's too sluggish, try it on Slacko 5.4.
There's a right way
There's a wrong way
And then there's my way

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-10, 00:40

Were the two windows the same istance
Yes, Opened from same menu, killing one kills the other.
39 Pale Moon processes is impossible
I counted 39 unique PID's labeled "palemoon" [38 children] looking at Htop in tree-view, when Htop was running again.
If possible, install version 28.
System came on a CD.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Finite-time Freeze?

Unread post by Walter Dnes » 2019-02-10, 01:23

moonbob69 wrote:System came on a CD.
Plan A) I assume that your system has some sort of "update software" function, like "apt-get", "yum", etc. See if a PM update is available.

Plan B) Download the 32-bit tarball from the direct link at http://linux.palemoon.org/datastore/release/palemoon-28.3.1.linux-i686.tar.bz2. From a terminal, extract to a directory with the commandline command tar xf palemoon-28.3.1.linux-i686.tar.bz2 Point your application launcher at the file called "palemoon" or "palemoon-bin".
There's a right way
There's a wrong way
And then there's my way

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-12, 23:43

extract to a directory
If these new files are put in a new directory, would running the new program from there interfere with or get confused with the existing Palemoon files? How do you have completely separate programs? For instance, where is "restore session" and "preferences" information kept?

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Finite-time Freeze?

Unread post by Walter Dnes » 2019-02-13, 00:45

moonbob69 wrote:If these new files are put in a new directory, would running the new program from there interfere with or get confused with the existing Palemoon files? How do you have completely separate programs? For instance, where is "restore session" and "preferences" information kept?
Profiles with that data, plus bookmarks etc etc, are in "$HOME/.moonchild productions/pale moon" (yes, with spaces). Cached images/data/etc are kept in "$HOME/.cache/.moonchild productions/pale moon"

PM 28.x will use your existing profile(s). Unlike a minor version upgrade, I believe that PM 28.x changes file formats in the profiles, and you can't go back to 27.x. Just in case things go wrong, I suggest that you back up the $HOME/.moonchild productions directory before setting up PM 28, so that you can restore it if necessary.
There's a right way
There's a wrong way
And then there's my way

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-13, 04:35

How do you have completely separate programs?
That is, to be able to run both at different times.

So, palemoon-bin doesn't need to be in a bin directory and all the libnss... don't need to be in a lib directory etc?

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-13, 07:55

moonbob69 wrote:
How do you have completely separate programs?
That is, to be able to run both at different times.

So, palemoon-bin doesn't need to be in a bin directory and all the libnss... don't need to be in a lib directory etc?
No programs ever need that.

User avatar
mmouse
Apollo supporter
Apollo supporter
Posts: 34
Joined: 2019-02-13, 06:47

Re: Finite-time Freeze?

Unread post by mmouse » 2019-02-13, 08:11

(...)
39 Pale Moon processes is impossible unless you open it with 39 different profiles, so there's something going on about not properly terminating the process.
Err, that's not impossible at all. A process can use threads (threads are a sort of subprocess, they are sharing memory with the 'true' process). In all versions of 'top' that I have seen, threads are hidden by default. In all 'htop' versions I have seen, threads are shown by default. If you show threads in top (H key), you will see many PIDs for Palemoon. This is normal, like all complex software Palemoon is a multithreaded program. If you hide threads in htop (F2 / Display Options / Hide userland process threads) you will see only one Palemoon line (unless several profiles have been setup indeed)

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-13, 15:30

mmouse wrote:Err, that's not impossible at all. A process can use threads (threads are a sort of subprocess, they are sharing memory with the 'true' process). In all versions of 'top' that I have seen, threads are hidden by default. In all 'htop' versions I have seen, threads are shown by default. If you show threads in top (H key), you will see many PIDs for Palemoon. This is normal, like all complex software Palemoon is a multithreaded program. If you hide threads in htop (F2 / Display Options / Hide userland process threads) you will see only one Palemoon line (unless several profiles have been setup indeed)
Threads might be implemented by recycling data structures at the kernel level, but they are not processes and shouldn't be treated as such. They are pieces of a single program running in parallel and sharing the same virtual memory.
If the problem is many Pale Moon instances, first we have to make sure they are not threads, because having many threads, as you said, is ok. On the other hand, having many Pale Moon processes (not threads) is bad unless multiple profiles are used.

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-14, 07:44

So what are "Tasks" that Htop reports?

I have never seen more than one parent Palemoon PID. Even when it is started again from the desktop manager, only more threads appear.

As long as the kernel code is issuing "process identification numbers" to threads opened by a user process, it would seem you have to admit that said thread is a process, just not an independent one. Can threads wait for interrupts, or is a thread only started (by an interrupt. possibly) and then expected to return when it is finished?

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-14, 08:28

moonbob69 wrote:So what are "Tasks" that Htop reports?

I have never seen more than one parent Palemoon PID. Even when it is started again from the desktop manager, only more threads appear.

As long as the kernel code is issuing "process identification numbers" to threads opened by a user process, it would seem you have to admit that said thread is a process, just not an independent one. Can threads wait for interrupts, or is a thread only started (by an interrupt. possibly) and then expected to return when it is finished?
You can start more "parent" Pale Moon processes by using different profiles.
Threads get a PID (or rather, a TID) only because threads came after Unix and Unix-based systems, so to avoid rewriting large parts of the kernel, resources have been recycled.
Microsoft Windows might implement things differently, in a way that threads don't get a PID (I don't know if it really is different, the point is that systems are not required to implement threads using the same data structures and management of processes.)
"Tasks" are a generic term and indeed can indicate both processes and threads. However, for the sake of finding a problem in a single-process-multiple-threads application, only proper processes should be listed, not threads.
I'm not sure what you mean by interrupts. Are you talking about Unix signals?
Anyway, yes, threads are required to return at some point in time. If they don't, they either completely block the process (say, indefinitely waiting on a join function), or simply use up resources.

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-15, 10:56

Interrupts are the physical hardware that causes a microprocessor to stop where it is executing, save that location (in a register or memory stack), and then begin executing somewhere else determined by the particulars of the interrupt. Usually caused by I/O hardware or the system timer, I would guess Unix/Linux signals could be set by the I/O routines started by the interrupt or by the timer routines, and then the system scheduler decides which thread get to execute again, where they can look at the signals.

I'm not that familiar with signals/messages in Windows or Linux. I assume there must be things besides I/O where one thread is expected to do something in response to a message from another thread, and the operating system will become unhappy if the unanswered messages get too numerous/use up all memory.

What are the kinds of things that keep the Linux kernel from processing input (mouse & keyboard)?
An infinite loop in a user thread shouldn't affect the mouse tracking. But there must be some compound action that waits, and in turn is waited for, in order to account for many minutes.

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-15, 12:30

I see.
Interrupts aren't visible at the user level, only inside the processor. An interrupt can't "start a thread" the same way a "userland" process does.
Unix signals are one way processes interact with each other: a process is unresponsive (e.g. inside an infinite loop), so a different process sends a signal to the unresponsive process. The first process will then interrupt the current action, jump to a routine that handles the signal and, if the handler didn't terminate the process, resume the previous computation.
The "kill" and "killall" programs do exactly this.
Signals are also used for stuff like segmentation faults (some programs can't die no matter what, so they handle this case on their own), or even to inform the process that a timer has stopped.
Inter-thread communication is performed by the process that spawns the thread. Usually it's with global variables protected by mutexes and whatnot, though other techniques exist.
The Linux kernel doesn't handle keyboard and mouse events in the very sense. What it does is get the data from the device (through an interrupt), convert it to a "standard" format (e.g. a keyboard sends certain signals when pressing a key, the kernel assign a letter to each signal), and then send it to a process that can handle the event as expected.
Usually this is the X server, but it might be Wayland or something else.
If the system doesn't have enough resources (not enough memory, busy CPU, etc), event handling will be slowed down.

Now that hopefully we have clarified what is going on behind the scene, I suggest going back to the original problem by following these steps:
1) have htop show only processes, not threads
2) try using the portable version of Pale Moon 28, so that you don't have to install it and your profile will not be changed
3) report back in case the problem persists with Pale Moon 28

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-16, 00:14

An interrupt can't "start a thread" the same way a "userland" process does.
The interrupt process (as computer architecture going back to the 8008) is the original thread method, except that when it starts it, by changing to a new address, there is no information outside the processor as to why it is going there until it changes some registers or memory.
a process is unresponsive (e.g. inside an infinite loop), so a different process sends a signal to the unresponsive process.
An infinite loop would be unresponsive, but not because of the loop- a calculation taking several seconds would look the same in terms of each computer time-tick. Its unresponsive because it didn't responds to messages. The way physical interrupts work, the interrupted program doesn't know it has been interrupted, unless it is keeping track of time by checking something outside of its code.

So is a thread or a process (the primary thread) required to check the time (a quicker way to see if it is time to check for messages), or check for messages, or do something else, if it hasn't finished its computing and tells the system to close itself?

If the X-desktop process is responsible for responding to keyboard & mouse & writing to screen, then I can see that a bug in it could cause a "freeze", even if the timer interrupt still works and other threads are computing. So if there is something that can turn on/off the error in the X process, that could also explain long intervals of "freeze".

I have the "palemoon-28.3.1.linux-i686.tar.bz2" but it was still unclear to me how to run it under a different name and without overwriting the profile for the older version.

"Www.palemoon.org/download.shtml#Portable_versions" seems to be only about Windows versions.

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Finite-time Freeze?

Unread post by vannilla » 2019-02-16, 00:48

Interrupts are used to notify the processor that something the processor expects to happen at some point in time, actually happen.
The most common event is when a peripheral device (think the hdd or the keyboard) completed its task. The processor will then complete the instruction it was performing then handle the interrupt.
Of course between multicore, hyperthreading, and all that, the processor can perform other tasks while the interrupt is handled.
That said, we are talking about threads created by the process, so interrupts have nothing to do with this. They interact with threads because they are part of the process, but that's it.

I guess I picked the wrong adjective when I used "unresponsive". Indeed, even when it never terminates, if a process receives a signal it still gives a response by running a handler, unless the OS places it in a specific state , but if it gets there unresponsiveness is the last concern (it's called uninterruptible sleep and it can happen e.g. when waiting for data from the net. No, this interrupt has nothing to do with processor interrupts.)

I hadn't checked what system the portable version was made for, but regardless, copy your ".moonchild production" folder (it has a space in the name) somewhere else that is not your home directory, then unpack version 28 somewhere and run it.

Walter Dnes
Astronaut
Astronaut
Posts: 650
Joined: 2015-07-30, 20:29
Location: Vaughan, ON, Canada

Re: Finite-time Freeze?

Unread post by Walter Dnes » 2019-02-16, 01:39

moonbob69 wrote:I have the "palemoon-28.3.1.linux-i686.tar.bz2" but it was still unclear to me how to run it under a different name and without overwriting the profile for the older version.
It can be done with some "tap-dancing", but I don't recommend doing it unless you really know what you're doing. Do you expect to constantly switch back and forth between 27.x and 28.x?
There's a right way
There's a wrong way
And then there's my way

User avatar
moonbob69
Moon lover
Moon lover
Posts: 85
Joined: 2019-02-06, 09:13

Re: Finite-time Freeze?

Unread post by moonbob69 » 2019-02-16, 03:40

...talking about threads created by the process, so interrupts have nothing to do with this
The only way a thread stops is if it decides it is done, decides to wait for something, or the CPU interrupts it, literally with the CPU hardware. This could be the result of external hardware; when the CPU is done with that, it resumes the interrupted thread, Or it could be the CPU's own timer interrupt; after handling that, the CPU may decide that the interrupted thread has had enough time, and resume another thread. Or it could be the CPU's error interrupt like page fault or divide-by-zero; that thread is not going to be resumed. Do threads get to set their own error entry points to respond to specific anticipated errors like divide-by-zero?
if a process receives a signal it still gives a response by running a handler
If a process has a handler, that sounds like interrupt-code itself; such code is only entitled to copy the information into its own memory space and return, and then work on that signal in its own time-slice later. How do signals work? Does a process have more than one entry point. or is the only entry point supposed to check for signals to see it it is being run for the first time or in response to a signal?

I had asked previously if anyone knew how the "unresponsive script" box was triggered, and how much trouble it would be to have a stop button that knew where scripts were and stop them.

Locked