Bug 2017281 - Cannot send emails: RangeError: Maximum call stack size exceeded.
Summary: Cannot send emails: RangeError: Maximum call stack size exceeded.
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: webkit2gtk3
Version: 35
Hardware: x86_64
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Michael Catanzaro
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-26 08:20 UTC by Marc K.
Modified: 2021-10-27 11:36 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-26 19:59:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
evolution &> logfile seemed to catch the relevant problems (15.27 KB, text/x-emacs-lisp)
2021-10-26 08:20 UTC, Marc K.
no flags Details
WebKit GPU Information (11.60 KB, text/plain)
2021-10-26 09:59 UTC, Marc K.
no flags Details


Links
System ID Private Priority Status Summary Last Updated
WebKit Project 232328 0 None None None 2021-10-26 19:59:53 UTC

Description Marc K. 2021-10-26 08:20:19 UTC
Created attachment 1837098 [details]
evolution &> logfile seemed to catch the relevant problems

When trying to send an email, no matter from what account, 
with what content and also with a freshly created user, 
I get a message popup like:

Could not create message.
You may need to select different mail options.
Detailed error: RangeError: Maximum call stack size exceeded.

or

Could not save to autosave file “.evolution-composer.autosave-T5CZB1”.
Error saving to autosave because “RangeError: Maximum call stack size exceeded.”.


in the editor window and the mail is not sent.


Version-Release number of selected component (if applicable): 3.42.0-1.fc35 

Steps to Reproduce:
1. start evolution
2. click on New
3. enter recipient in To field
4. click on Send 

Actual results:
Error message popup appears, editor window stays open, mail is not sent.


Expected results:
Editor window is closed and mail is sent.


Additional info:
The problem occurs on wayland with NVIDIA GeForce GTX 1650 using the nouveau and nvidia driver 470.74.
The problem does not occur on my notebook with Fedora 35, wayland and Intel graphics.

Comment 1 Milan Crha 2021-10-26 08:54:00 UTC
Thanks for a bug report. I also cannot reproduce this. It looks like a WebKitGTK error. What is the webkit2gtk3 package version, please?

Michael, is there an easy way to get the backtrace from the JavaScript call, please?

Comment 2 Marc K. 2021-10-26 09:06:06 UTC
(In reply to Milan Crha from comment #1)
> Thanks for a bug report. I also cannot reproduce this. It looks like a
> WebKitGTK error. What is the webkit2gtk3 package version, please?

Thanks for the quick response! The webkit2gtk3 version is 2.34.0-1.fc35

Comment 3 Milan Crha 2021-10-26 09:18:41 UTC
Good, I've the same version, but I do not have an NVidia card, thus I might be in the same group as your second machine.

When you close Evolution and run:

   $ gsettings set org.gnome.evolution.shell webkit-developer-mode true

in a terminal, then when you run Evolution again it'll contain a new item in the Help menu, something with "GPU" in the name, which will show, in the preview panel, the information provided by WebKit about the graphics drivers it uses.

It seems there are also used WEBKIT_DISABLE_COMPOSITING_MODE=1 and WEBKIT_FORCE_COMPOSITING_MODE=0 in the WebKit sources, thus you can also try to run Evolution from the terminal, with those variables exported.

The only thing is that I'd not expect these things influencing the Javascript call stack limits, but I do not know WebKit internals at all.

Comment 4 Marc K. 2021-10-26 09:59:20 UTC
Created attachment 1837134 [details]
WebKit GPU Information

I've copied the text after executing

gsettings set org.gnome.evolution.shell webkit-developer-mode true

from the WebKit GPU Information frame

Comment 5 Marc K. 2021-10-26 10:04:46 UTC
> 
> It seems there are also used WEBKIT_DISABLE_COMPOSITING_MODE=1 and
> WEBKIT_FORCE_COMPOSITING_MODE=0 in the WebKit sources, thus you can also try
> to run Evolution from the terminal, with those variables exported.
> 
> The only thing is that I'd not expect these things influencing the
> Javascript call stack limits, but I do not know WebKit internals at all.

Thanks, starting evolution with: 

LC_ALL=C WEBKIT_FORCE_COMPOSITING_MODE=0 WEBKIT_DISABLE_COMPOSITING_MODE=1 evolution 

indeed does not help. With webkit-developer-mode=true, the log now also contains repeated lines with:

CONSOLE JS ERROR RangeError: Maximum call stack size exceeded.

Comment 6 Marc K. 2021-10-26 12:17:37 UTC
An upgrade to webkit2gtk3-2.34.1-2.fc35.x86_64 from updates-testing also did not resolve the issue.

Comment 7 Michael Catanzaro 2021-10-26 12:43:38 UTC
(In reply to Marc K. from comment #5)
> CONSOLE JS ERROR RangeError: Maximum call stack size exceeded.

I've never seen this before. You need to get access to the Console tab in the web inspector to see what is going on. I think if you have a way to open the web inspector, then it should show more detail.

It sounds like Evolution's webkit-developer-mode feature probably enables WebKit's enable-developer-extras setting. Try pressing Ctrl+Shift+I in your mail with that setting enabled to see if you can open the inspector. Will be interesting to see what's shown on the Console tab.

Comment 8 Michael Catanzaro 2021-10-26 12:46:43 UTC
(In reply to Marc K. from comment #0)
> Additional info:
> The problem occurs on wayland with NVIDIA GeForce GTX 1650 using the nouveau
> and nvidia driver 470.74.
> The problem does not occur on my notebook with Fedora 35, wayland and Intel
> graphics.

There's no way this is related to graphics.

Have you set any special resource limits on the affected computer? Maybe 'ulimit -s'?

What happens if you run with the environment variable JavaScriptCoreUseJIT=0?

Comment 9 Milan Crha 2021-10-26 12:52:00 UTC
> Try pressing Ctrl+Shift+I in your mail with that setting enabled to see if you can open the inspector.

Right, that works in a mail window (when double-clicking a message). When used in the mail view it opens a new assigned task window. Ctlr+Shift+D is an alternative shortcut for the inspector.

Comment 10 Marc K. 2021-10-26 14:15:10 UTC
(In reply to Michael Catanzaro from comment #7)
> (In reply to Marc K. from comment #5)
> > CONSOLE JS ERROR RangeError: Maximum call stack size exceeded.
> 
> I've never seen this before. You need to get access to the Console tab in
> the web inspector to see what is going on. I think if you have a way to open
> the web inspector, then it should show more detail.
> 
> It sounds like Evolution's webkit-developer-mode feature probably enables
> WebKit's enable-developer-extras setting. Try pressing Ctrl+Shift+I in your
> mail with that setting enabled to see if you can open the inspector. Will be
> interesting to see what's shown on the Console tab.

After pressing Ctrl+Shift+I a couple of times, the Web-Inspector window opens, but is and stays absolutely empty.

Comment 11 Marc K. 2021-10-26 14:23:43 UTC
(In reply to Michael Catanzaro from comment #8)
> (In reply to Marc K. from comment #0)
> > Additional info:
> > The problem occurs on wayland with NVIDIA GeForce GTX 1650 using the nouveau
> > and nvidia driver 470.74.
> > The problem does not occur on my notebook with Fedora 35, wayland and Intel
> > graphics.
> 
> There's no way this is related to graphics.
My first idea was that this was related to some outdated gtk or gnome theme, but it also happens with a fresh user; and also with Xorg.


> 
> Have you set any special resource limits on the affected computer? Maybe
> 'ulimit -s'?

No, I don't think so, ulimit -s says unlimited.

> 
> What happens if you run with the environment variable JavaScriptCoreUseJIT=0?

Nothing changes. I think I have tried most WebKit environment variables by now.

Comment 12 Marc K. 2021-10-26 14:51:25 UTC
I've now fully upgraded to updates-testing. 

Now, evolution crashes immediately on wayland with:

evolution: ../src/wayland-thread.c:87: wlExternalApiLock: Assertion `!"failed to lock pthread mutex"' failed.

Haven't tried Xorg, yet.

Comment 13 Michael Catanzaro 2021-10-26 14:54:31 UTC
(In reply to Marc K. from comment #11)
> > Have you set any special resource limits on the affected computer? Maybe
> > 'ulimit -s'?
> 
> No, I don't think so, ulimit -s says unlimited.

Er... are you sure? When I run 'ulimit -s' I get 8192, so that's what I would have expected....

Comment 14 Marc K. 2021-10-26 15:29:20 UTC
(In reply to Michael Catanzaro from comment #13)
> (In reply to Marc K. from comment #11)
> > > Have you set any special resource limits on the affected computer? Maybe
> > > 'ulimit -s'?
> > 
> > No, I don't think so, ulimit -s says unlimited.
> 
> Er... are you sure? When I run 'ulimit -s' I get 8192, so that's what I
> would have expected....

Yes, I had to change this for some other reasons (a heavy RocksDB application, I think).
But indeed, I haven't tried to reproduce the bug on a clean install, yet.

Comment 15 Michael Catanzaro 2021-10-26 16:01:58 UTC
Well that's probably somehow related. Try changing it back to a fixed value?

Comment 16 Marc K. 2021-10-26 16:38:38 UTC
(In reply to Michael Catanzaro from comment #15)
> Well that's probably somehow related. Try changing it back to a fixed value?

Damn, that's right!

ulimit -s 8192

fixes the problem completely. No more warnings at all. Thanks! 

Maybe the issue should nevertheless be reported for webkit2gtk3. Setting maximum stack size ulimit probably shouldn't have such an effect.

Comment 17 Michael Catanzaro 2021-10-26 16:59:34 UTC
I agree, I think this is a bug in JSC::VM::updateStackLimits.

Comment 18 Marc K. 2021-10-26 18:36:20 UTC
(In reply to Michael Catanzaro from comment #17)
> I agree, I think this is a bug in JSC::VM::updateStackLimits.

I guess StackBounds::currentThreadStackBoundsInternal is the root cause.

Comment 19 Michael Catanzaro 2021-10-26 19:12:25 UTC
Ah, you're probably right, because I see getrlimit() there!

So I was searching for the wrong function, and in the wrong place (I was only searching under JSC, but this is under WTF).

Comment 20 Marc K. 2021-10-26 19:29:31 UTC
(In reply to Michael Catanzaro from comment #19)
> Ah, you're probably right, because I see getrlimit() there!
> 

Yes, getrlimit(RLIMIT_STACK) returns -1 for ulimit -s unlimited, which is not caught there.

#include <sys/resource.h>
#include <stdio.h>

void main() {
  struct rlimit limit;

  if (getrlimit(RLIMIT_STACK , &limit) == 0) {
    rlim_t size = limit.rlim_cur;
    printf("stack size limit: %lld\n", size);
  }
}

> So I was searching for the wrong function, and in the wrong place (I was
> only searching under JSC, but this is under WTF).

You gave me the idea in the first place that unlimited is probably an uncaught -1 somewhere.

Comment 21 Michael Catanzaro 2021-10-26 19:59:53 UTC
OK, thanks. Let's continue upstream: https://bugs.webkit.org/show_bug.cgi?id=232328


Note You need to log in before you can comment on or make changes to this bug.