Bug: context/mtxrun makes Firefox eat up cpu

newer
\blank[] doesn't work when nothing...

Sylvain Hubert

29 Oct 2020 29 Oct '20

11:29 a.m.

Hi, sorry if this is not the best place to file a bug but I found no working bug tracker for context. Environment: Manjaro 20.1.2, context 2020.09.20 23:02, firefox 82.0 Step to reproduce: 1. `firefox --safe-mode # start firefox without add-ons` 2.a`context --version # or --help, or without arguments` 2.b or: `mtxrun --script font --list --all` Expected behavior: Nothing surprising should happen. Actual behavior: Firefox suddenly eats 100% of cpu I've noticed that `context` symlinks to `luametatex`, but the latter itself does not trigger the bug, neither do `luatex` or `latex`, so I believe this is a context-specific thing. Best, Sylvain

Attachments:

attachment.html (text/html — 934 bytes)

Show replies by date

Taco Hoekwater

29 Oct 29 Oct

noon

...

On 29 Oct 2020, at 11:29, Sylvain Hubert wrote:

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Should you not be looking for a bug tracker for firefox instead? It looks like firefox in safe mode is perhaps trying to do something with (or waiting for ?) a shell command called ‘context’, which is presumably not related to ‘our’ ConTeXt. You can test that by (temporarily) redirecting the ‘context’ command from ‘luametatex’ to ‘ls’ (but keep it at the same path), and see if the problem persists. If so, then it is the actual name giving problems, and then can you should file a firefox bug report because then it has nothing to do with ConText itself. But even if the above is not the actual issue, it still sounds like a firefox problem to me. Best wishes, Taco

Sylvain Hubert

12:15 p.m.

Hi Taco, thanks for the suggestions, but as mentioned earlier, `mtxrun --script font --list --all` triggers the same problem as `context` does. I guess the problem might have something to do with fonts, but since `context` aka `luametatex` is not open source yet, I can't analyse further. Best, Sylvain On Thu, 29 Oct 2020 at 12:02, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 11:29, Sylvain Hubert wrote:

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Should you not be looking for a bug tracker for firefox instead?

It looks like firefox in safe mode is perhaps trying to do something with (or waiting for ?) a shell command called ‘context’, which is presumably not related to ‘our’ ConTeXt.

You can test that by (temporarily) redirecting the ‘context’ command from ‘luametatex’ to ‘ls’ (but keep it at the same path), and see if the problem persists. If so, then it is the actual name giving problems, and then can you should file a firefox bug report because then it has nothing to do with ConText itself.

But even if the above is not the actual issue, it still sounds like a firefox problem to me.

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Sylvain Hubert

12:19 p.m.

And using safe mode here is just to make sure that the problem is not caused by extensions. The annoyance started long before I bothered opening firefox with an extra argument. On Thu, 29 Oct 2020 at 12:02, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 11:29, Sylvain Hubert wrote:

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Should you not be looking for a bug tracker for firefox instead?

It looks like firefox in safe mode is perhaps trying to do something with (or waiting for ?) a shell command called ‘context’, which is presumably not related to ‘our’ ConTeXt.

You can test that by (temporarily) redirecting the ‘context’ command from ‘luametatex’ to ‘ls’ (but keep it at the same path), and see if the problem persists. If so, then it is the actual name giving problems, and then can you should file a firefox bug report because then it has nothing to do with ConText itself.

But even if the above is not the actual issue, it still sounds like a firefox problem to me.

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Taco Hoekwater

12:31 p.m.

...

On 29 Oct 2020, at 12:19, Sylvain Hubert wrote:

And using safe mode here is just to make sure that the problem is not caused by extensions. The annoyance started long before I bothered opening firefox with an extra argument.

I am baffled then. I do not see the connection, at all. Best wishes, Taco

Sylvain Hubert

12:44 p.m.

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something. On Thu, 29 Oct 2020 at 12:33, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 12:19, Sylvain Hubert wrote:

And using safe mode here is just to make sure that the problem is not caused by extensions. The annoyance started long before I bothered opening firefox with an extra argument.

I am baffled then. I do not see the connection, at all.

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Taco Hoekwater

1:55 p.m.

...

On 29 Oct 2020, at 12:44, Sylvain Hubert wrote:

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something.

But it seems to be a big problem only on your machine. What hardware are you running on? Is it a Raspberry PI? Like any TeX-related program, ConTeXt does a fair bit of disk access while starting up, but I haven’t heard of that being an actual problem since the age of single-core CPUs. And it certainly should not have an effect on the CPU usage of any other program (it could affect system responsiveness, though). Best wishes, Taco

Sylvain Hubert

3:14 p.m.

...

But it seems to be a big problem only on your machine I fail to see what this implies.

...

What hardware are you running on? Is it a Raspberry PI? No, it's Core i5 + 8G ram + ssd.

...

Like any TeX-related program, ConTeXt does a fair bit of disk access while starting up. But none of the other TeX-related programs causes such a problem here.

...

And it certainly should not have an effect on the CPU usage of any other program. Indeed it should not have such an effect, so it failed to avoid what I should have avoided, and that's why it's a bug to be discovered and eliminated.

On Thu, 29 Oct 2020 at 13:56, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 12:44, Sylvain Hubert wrote:

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something.

But it seems to be a big problem only on your machine. What hardware are you running on? Is it a Raspberry PI?

Like any TeX-related program, ConTeXt does a fair bit of disk access while starting up, but I haven’t heard of that being an actual problem since the age of single-core CPUs. And it certainly should not have an effect on the CPU usage of any other program (it could affect system responsiveness, though).

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Taco Hoekwater

4:38 p.m.

...

On 29 Oct 2020, at 15:14, Sylvain Hubert wrote:

...
But it seems to be a big problem only on your machine I fail to see what this implies.

The point is that if this was a common problem, many users would complain or at least respond to your message with a “me too”. So it seems likely that there is something special going on with exactly your computer or your context installation. What binary are you using for luametatex ? The normal linux 64-bit one from the lmtx distribution? Best wishes, Taco

Sylvain Hubert

5:44 p.m.

...

So it seems likely that there is something special going on with exactly your computer or your context installation. Still, I fail to see what this implies. In particular, I find it not the most professional to assume a dust-proof environment for a real-world product, and even unreasonable to assume that for something like `context --help` given that no other commands are making a scene when printing help messages.

What binary are you using for luametatex ? The normal linux 64-bit one from the lmtx distribution? Yes, it is. On Thu, 29 Oct 2020 at 16:43, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 15:14, Sylvain Hubert wrote:

...
But it seems to be a big problem only on your machine I fail to see what this implies.

The point is that if this was a common problem, many users would complain or at least respond to your message with a “me too”. So it seems likely that there is something special going on with exactly your computer or your context installation.

What binary are you using for luametatex ? The normal linux 64-bit one from the lmtx distribution?

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Hans Hagen

6:15 p.m.

On 10/29/2020 5:44 PM, Sylvain Hubert wrote:

...

...
So it seems likely that there is something special going on with exactly your computer or your context installation. Still, I fail to see what this implies. In particular, I find it not the most professional to assume a dust-proof environment for a real-world product, and even unreasonable to assume that for something like `context --help` given that no other commands are making a scene when printing help messages. So what does context --help show?

Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Sylvain Hubert

3:18 p.m.

I would consider it more constructive to admit the existence of the bug and find a way look into the source code of luametatex, since `context --help` is obviously not a terribly complicated routine to investigate. On Thu, 29 Oct 2020 at 13:56, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 12:44, Sylvain Hubert wrote:

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something.

But it seems to be a big problem only on your machine. What hardware are you running on? Is it a Raspberry PI?

Like any TeX-related program, ConTeXt does a fair bit of disk access while starting up, but I haven’t heard of that being an actual problem since the age of single-core CPUs. And it certainly should not have an effect on the CPU usage of any other program (it could affect system responsiveness, though).

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Hans Hagen

4:04 p.m.

On 10/29/2020 3:18 PM, Sylvain Hubert wrote:

...

I would consider it more constructive to admit the existence of the bug and find a way look into the source code of luametatex, since `context --help` is obviously not a terribly complicated routine to investigate. As taco mentioned, it's very unlikely an engine issue esp as firefox is somehow involved. A tex engine really does nothing special; just openign a few files.

What is your test file? Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

ntg＠scorecrow.com

30 Oct 30 Oct

9:34 a.m.

Hi Sylvain, This bug tracker report https://bugzilla.mozilla.org/show_bug.cgi?id=1599329 describes lagging / freezing (which are symptoms of excessive CPU usage, of course) for versions of Firefox from 70 to 74 inclusive on Manjaro. They also report Chromium seeing the same problem. These symptoms seem to be very similar to yours. Could you please try their steps to reproduce - namely view a video in Firefox - and do so from a fresh reboot without starting or invoking ConTeXt so we can be sure that it is excluded from the equation? If you get excessive CPU usage following their steps then it is Firefox at fault. If you don't then it might not be - unfortunately it only narrows it down to a 'might'. Regards,

...

On 29 Oct 2020, at 11:44, Sylvain Hubert wrote:

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something.

On Thu, 29 Oct 2020 at 12:33, Taco Hoekwater wrote:

...
On 29 Oct 2020, at 12:19, Sylvain Hubert wrote:

And using safe mode here is just to make sure that the problem is not caused by extensions. The annoyance started long before I bothered opening firefox with an extra argument.

I am baffled then. I do not see the connection, at all.

-- Bruce Horrocks Hampshire, UK

Taco Hoekwater

10:06 a.m.

...

On 30 Oct 2020, at 09:34, ntg@scorecrow.com wrote:

Hi Sylvain,

This bug tracker report https://bugzilla.mozilla.org/show_bug.cgi?id=1599329 describes lagging / freezing (which are symptoms of excessive CPU usage, of course) for versions of Firefox from 70 to 74 inclusive on Manjaro. They also report Chromium seeing the same problem.

This basically says it is a bug in the video driver. You could test that theory by switching to a text terminal for running the ‘context’ command (assuming the text-only terminal is still accessible in Manjaro) and see whether the output of ‘context —help’ causes lag there as well. Even a really, really crappy video driver should be able to handle the output stream in full-screen text mode, so if it still lags in that environment, that moves the needle toward a problem in ConTeXt (however unlikely Hans and I think that is). Best wishes, Taco

Sylvain Hubert

7:44 p.m.

...

You could test that theory by switching to a text terminal for running the ‘context’ command (assuming the text-only terminal is still accessible in Manjaro) and see whether the output of ‘context —help’ causes lag there as well.

If I understand you correctly, here's what I've tried: 1. open firefox, open no webpages, so there's only one about:blank 2. ctrl+alt+2, login, `context --help` 3. (in the text interface) `htop`, firefox cpu usage rises to 100% after ~1s. On Fri, 30 Oct 2020 at 10:07, Taco Hoekwater wrote:

...

...
On 30 Oct 2020, at 09:34, ntg@scorecrow.com wrote:

Hi Sylvain,

This bug tracker report < https://bugzilla.mozilla.org/show_bug.cgi?id=1599329> describes lagging / freezing (which are symptoms of excessive CPU usage, of course) for versions of Firefox from 70 to 74 inclusive on Manjaro. They also report Chromium seeing the same problem.

This basically says it is a bug in the video driver.

You could test that theory by switching to a text terminal for running the ‘context’ command (assuming the text-only terminal is still accessible in Manjaro) and see whether the output of ‘context —help’ causes lag there as well. Even a really, really crappy video driver should be able to handle the output stream in full-screen text mode, so if it still lags in that environment, that moves the needle toward a problem in ConTeXt (however unlikely Hans and I think that is).

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Sylvain Hubert

8:14 p.m.

A few new experiments: 1. `firefox --headless` stays quite no matter what 2. when `gimp` is running, `context --help` causes a rise of cpu usage of gimp up to 60% for ~1s 3. when only xfce4-terminal is running, I tried `context --help` for a few times and for each time, one of the following experiences a cpu usage rise up to >50% for ~1s: libwhispermenu.so libpulseaudio.so xfce4-appfinder nm-applet Thunar xfce4-terminal On Fri, 30 Oct 2020 at 10:07, Taco Hoekwater wrote:

...

...
On 30 Oct 2020, at 09:34, ntg@scorecrow.com wrote:

Hi Sylvain,

This bug tracker report < https://bugzilla.mozilla.org/show_bug.cgi?id=1599329> describes lagging / freezing (which are symptoms of excessive CPU usage, of course) for versions of Firefox from 70 to 74 inclusive on Manjaro. They also report Chromium seeing the same problem.

This basically says it is a bug in the video driver.

You could test that theory by switching to a text terminal for running the ‘context’ command (assuming the text-only terminal is still accessible in Manjaro) and see whether the output of ‘context —help’ causes lag there as well. Even a really, really crappy video driver should be able to handle the output stream in full-screen text mode, so if it still lags in that environment, that moves the needle toward a problem in ConTeXt (however unlikely Hans and I think that is).

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Hans Hagen

8:26 p.m.

On 10/30/2020 8:14 PM, Sylvain Hubert wrote:

...

A few new experiments: 1. `firefox --headless` stays quite no matter what 2. when `gimp` is running, `context --help` causes a rise of cpu usage of gimp up to 60% for ~1s 3. when only xfce4-terminal is running, I tried `context --help` for a few times and for each time, one of the following experiences a cpu usage rise up to >50% for ~1s:

libwhispermenu.so libpulseaudio.so xfce4-appfinder nm-applet Thunar xfce4-terminal so taco's analysis about the video seems right .. are there alternative terminals?

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

Sylvain Hubert

7:48 p.m.

Hi Bruce,

...

Could you please try their steps to reproduce - namely view a video in Firefox - and do so from a fresh reboot without starting or invoking ConTeXt so we can be sure that it is excluded from the equation?

Thanks for the suggestion but firefox here has never had any issue playing a youtube video with 6 other video pages and 20 other news pages opened at the same time, and the bug can be reproduced here with just an about:blank and no video opened. On Fri, 30 Oct 2020 at 09:50, wrote:

...

Hi Sylvain,

This bug tracker report < https://bugzilla.mozilla.org/show_bug.cgi?id=1599329> describes lagging / freezing (which are symptoms of excessive CPU usage, of course) for versions of Firefox from 70 to 74 inclusive on Manjaro. They also report Chromium seeing the same problem.

These symptoms seem to be very similar to yours. Could you please try their steps to reproduce - namely view a video in Firefox - and do so from a fresh reboot without starting or invoking ConTeXt so we can be sure that it is excluded from the equation?

If you get excessive CPU usage following their steps then it is Firefox at fault. If you don't then it might not be - unfortunately it only narrows it down to a 'might'.

Regards,

...
On 29 Oct 2020, at 11:44, Sylvain Hubert wrote:

I've just tried chromium which behaves a bit better but still experiences a sudden raise of cpu usage from <10% to >70% during ~1s. I've also noticed that, even without any browser running, each time after I compile a file with `context`, my terminal get stuck for ~1s. So I'm pretty sure this is a context bug, probably caused by unnecessary excessive disk operations or something.

On Thu, 29 Oct 2020 at 12:33, Taco Hoekwater wrote:

...
On 29 Oct 2020, at 12:19, Sylvain Hubert wrote:

And using safe mode here is just to make sure that the problem is not caused by extensions. The annoyance started long before I bothered opening firefox with an extra argument.

I am baffled then. I do not see the connection, at all.

-- Bruce Horrocks Hampshire, UK

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Hans Hagen

8:28 p.m.

On 10/30/2020 7:48 PM, Sylvain Hubert wrote:

...

Hi Bruce,

...
Could you please try their steps to reproduce - namely view a video in Firefox - and do so from a fresh reboot without starting or invoking ConTeXt so we can be sure that it is excluded from the equation?

Thanks for the suggestion but firefox here has never had any issue playing a youtube video with 6 other video pages and 20 other news pages opened at the same time, and the bug can be reproduced here with just an about:blank and no video opened. youtube is not a terminal app so it doesn't force some video mode switch

Sylvain Hubert

29 Oct 29 Oct

12:26 p.m.

Update: `mtxrun --script # without more arguments` triggers the same problem. On Thu, 29 Oct 2020 at 12:02, Taco Hoekwater wrote:

...

...
On 29 Oct 2020, at 11:29, Sylvain Hubert wrote:

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Should you not be looking for a bug tracker for firefox instead?

It looks like firefox in safe mode is perhaps trying to do something with (or waiting for ?) a shell command called ‘context’, which is presumably not related to ‘our’ ConTeXt.

You can test that by (temporarily) redirecting the ‘context’ command from ‘luametatex’ to ‘ls’ (but keep it at the same path), and see if the problem persists. If so, then it is the actual name giving problems, and then can you should file a firefox bug report because then it has nothing to do with ConText itself.

But even if the above is not the actual issue, it still sounds like a firefox problem to me.

Best wishes, Taco

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Aditya Mahajan

4:48 p.m.

On Thu, 29 Oct 2020, Sylvain Hubert wrote:

...

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Environment: Manjaro 20.1.2, context 2020.09.20 23:02, firefox 82.0

Step to reproduce: 1. `firefox --safe-mode # start firefox without add-ons` 2.a`context --version # or --help, or without arguments` 2.b or: `mtxrun --script font --list --all`

Expected behavior: Nothing surprising should happen.

Actual behavior: Firefox suddenly eats 100% of cpu

I cannot reproduce this behavior (I am on manjaro but using firefox 81 rather than 82). My environment: $uname -a Linux hostname 5.4.67-1-MANJARO #1 SMP PREEMPT Wed Sep 23 14:20:18 UTC 2020 x86_64 GNU/Linux $firefox --version Mozilla Firefox 81.0 $context --version mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /opt/luametatex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.09.15 18:11 mtx-context | main context file: /opt/luametatex/texmf-context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.09.15 18:11 I followed your steps: 1. start `firefox --safe-mode` 2. On a different terminal, open htop and filter `firefox` so I can view firefox's CPU usage. 3. Run `mtxrun --script font --list --all` The CPU usage of firefox does not change in any appreciable way (it was 0% and remains 0%). It is possible for you to check on a fresh install of manjaro in a virtual machine to rule out the possibility that something else in your system is causing this behavior. Aditya

Sylvain Hubert

5:56 p.m.

Hi aditya,

...

It is possible for you to check on a fresh install of manjaro in a virtual machine to rule out the possibility that something else in your system is causing this behavior. I remember trying context while browsing the wiki before so it should work normally in a brand new environment, but I don't think it's reasonable to install a brand new distro just to make sure that 'context --help' can work normally, no matter how problematic the current distro is, as long as it does not prevent commands from displaying help messages.

On Thu, 29 Oct 2020 at 16:50, Aditya Mahajan wrote:

...

On Thu, 29 Oct 2020, Sylvain Hubert wrote:

...
Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Environment: Manjaro 20.1.2, context 2020.09.20 23:02, firefox 82.0

Step to reproduce: 1. `firefox --safe-mode # start firefox without add-ons` 2.a`context --version # or --help, or without arguments` 2.b or: `mtxrun --script font --list --all`

Expected behavior: Nothing surprising should happen.

Actual behavior: Firefox suddenly eats 100% of cpu

I cannot reproduce this behavior (I am on manjaro but using firefox 81 rather than 82). My environment:

$uname -a Linux hostname 5.4.67-1-MANJARO #1 SMP PREEMPT Wed Sep 23 14:20:18 UTC 2020 x86_64 GNU/Linux

$firefox --version Mozilla Firefox 81.0

$context --version mtx-context | ConTeXt Process Management 1.03 mtx-context | mtx-context | main context file: /opt/luametatex/texmf-context/tex/context/base/mkiv/context.mkiv mtx-context | current version: 2020.09.15 18:11 mtx-context | main context file: /opt/luametatex/texmf-context/tex/context/base/mkiv/context.mkxl mtx-context | current version: 2020.09.15 18:11

I followed your steps: 1. start `firefox --safe-mode` 2. On a different terminal, open htop and filter `firefox` so I can view firefox's CPU usage. 3. Run `mtxrun --script font --list --all`

The CPU usage of firefox does not change in any appreciable way (it was 0% and remains 0%).

It is possible for you to check on a fresh install of manjaro in a virtual machine to rule out the possibility that something else in your system is causing this behavior.

Aditya

___________________________________________________________________________________ If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net

___________________________________________________________________________________

Sylvain Hubert

4 Nov 4 Nov

4:01 p.m.

The problem disappeared after a fresh installation of context with everything else untouched. On Thu, 29 Oct 2020 at 11:29, Sylvain Hubert wrote:

...

Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Environment: Manjaro 20.1.2, context 2020.09.20 23:02, firefox 82.0

Step to reproduce: 1. `firefox --safe-mode # start firefox without add-ons` 2.a`context --version # or --help, or without arguments` 2.b or: `mtxrun --script font --list --all`

Expected behavior: Nothing surprising should happen.

Actual behavior: Firefox suddenly eats 100% of cpu

I've noticed that `context` symlinks to `luametatex`, but the latter itself does not trigger the bug, neither do `luatex` or `latex`, so I believe this is a context-specific thing.

Best, Sylvain

Sylvain Hubert

5 Nov 5 Nov

11:48 a.m.

After dozens of compilations of various minimal examples using the newly installed context, the problem reappeared. Removing tex/texmf-cache does not help. Does anyone know what files context modifies apart from tex/texmf-cache? Sylvain On Wed, 4 Nov 2020 at 16:01, Sylvain Hubert wrote:

...

The problem disappeared after a fresh installation of context with everything else untouched.

On Thu, 29 Oct 2020 at 11:29, Sylvain Hubert wrote:

...
Hi,

sorry if this is not the best place to file a bug but I found no working bug tracker for context.

Environment: Manjaro 20.1.2, context 2020.09.20 23:02, firefox 82.0

Step to reproduce: 1. `firefox --safe-mode # start firefox without add-ons` 2.a`context --version # or --help, or without arguments` 2.b or: `mtxrun --script font --list --all`

Expected behavior: Nothing surprising should happen.

Actual behavior: Firefox suddenly eats 100% of cpu

I've noticed that `context` symlinks to `luametatex`, but the latter itself does not trigger the bug, neither do `luatex` or `latex`, so I believe this is a context-specific thing.

Best, Sylvain

Taco Hoekwater

12:01 p.m.

...

On 5 Nov 2020, at 11:48, Sylvain Hubert wrote:

After dozens of compilations of various minimal examples using the newly installed context, the problem reappeared.

Removing tex/texmf-cache does not help.

Does anyone know what files context modifies apart from tex/texmf-cache?

None. Are you sure your disk(-driver) is OK? Taco

Sylvain Hubert

12:49 p.m.

On Thu, 5 Nov 2020 at 12:07, Taco Hoekwater wrote:

...

...
On 5 Nov 2020, at 11:48, Sylvain Hubert wrote:

After dozens of compilations of various minimal examples using the newly installed context, the problem reappeared.

Removing tex/texmf-cache does not help.

Does anyone know what files context modifies apart from tex/texmf-cache?

None.

Are you sure your disk(-driver) is OK?

tbh I'm not sure. I tried to figure that out by experimenting with different kinds of stress tests and none of them triggered the same problem, but I don't have much experience on this kind of problem anyway.

Hans Hagen

12:25 p.m.

On 11/5/2020 11:48 AM, Sylvain Hubert wrote:

...

After dozens of compilations of various minimal examples using the newly installed context, the problem reappeared.

Removing tex/texmf-cache does not help. Removing firefoxe does ... when I open e.g. the cnn website in firefox (for instance to keep an eye on crazy elections), that program takes 650 MB memory and 44% GPU while edge (or chrome) takes 270 MB mem and 3% GPU. Add a few more tabs and firefox will easily eat up gigs of mem.

Now, I don't know how it manages memory but the tex engine needs a few reasonable sized arrays but in large allocs and then it manages its own memory from that pool, Lua needs more mem (could be scattered due to allocs i guess), and soem garbage collection can kick in, and browsers ... well i suppose lots of allocations and it also depends on the jasvascript vm. So, I would not be surprised if after some runs of these programs you end up with scattered memory. I suppose that at some point the operating system (when in rest) will sort things out. When I make a format file it normally takes a few seconds. When I let firefox run wild on memory (top out mem and then let it give back some), it can take twice as much to make a format, but after quitting firefox it's all ok again. Anyway, already long ago I decided that firefox is a memory hog so whenever I do something that takes more time than I susspect, I close firefox. Actually I often close browsers when i don't need them, also because they always seem to be busy with something (also the network). Tex is just juggling some bytes. In the past tex and distributioen were considered large ... nowadays they are small compared to whatever you install and run. And in luametatex/context the performance bottleneck is lua, not the core tex engine. Of course you could consider swithcing to another operating system. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

1508

Age (days ago)

1515

Last active (days ago)

List overview

Download

27 comments

5 participants

participants (5)

Aditya Mahajan
Hans Hagen
ntg＠scorecrow.com
Sylvain Hubert
Taco Hoekwater

Bug: context/mtxrun makes Firefox eat up cpu

tags

participants (5)