Thanks for a bug report. I would simply suggest to follow the instructions from the error message, but I see that this crashed in the WebKitWebProcess, something what is run on its own. But maybe trying with it anyway would help a bit, thus, please run the evolution as:

   $ GDK_SYNCHRONIZE=1 evolution

and see what it'll do. Having a backtrace, with debug info packages installed for the evolution and evolution-data-server, will help to narrow where the issue happened and possibly also why. If you have and crash catcher in your system, which would record the backtrace, then it'll be useful.

There are other options too, but they are very techy.

(In reply to Milan Crha from comment #1)
> Thanks for a bug report. I would simply suggest to follow the instructions
> from the error message, but I see that this crashed in the WebKitWebProcess,
> something what is run on its own. But maybe trying with it anyway would help
> a bit, thus, please run the evolution as:
> 
>    $ GDK_SYNCHRONIZE=1 evolution
> 
> and see what it'll do.

Yes, that should work. We need a web process backtrace taken with GDK_SYNCHRZONIZE=1. In general, you should never report crashes on Bugzilla without a backtrace since there's nothing we can do without one. The backtrace will most likely indicate this is a bug in WebKit; we can give you instructions for reporting a WebKit bug once we have a high-quality backtrace here.

We also need to know the exact version of WebKitGTK+. A similar issue was fixed in 2.14.1, the latest version, so if you're still on 2.14.0 then it's probably already fixed. If you've already upgraded to 2.14.1, then we'd like a WebKit bug report.

Canned reply about getting a backtrace:

Thanks for taking the time to report this.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for more information on how to do so. When pasting a stack trace in this bug report, please reset the status of this bug report from NEEDINFO to its previous status. Thanks in advance!

# export GDK_SYNCHRONIZE=1
# GDK_SYNCHRONIZE=1 evolution
Same error:
(WebKitWebProcess:1654): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 212 error_code 2 request_code 153 (GLX) minor_code 24)
  (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.)

(evolution:1632): camel-WARNING **: Didn't get valid response from ntlm_auth helper

(WebKitWebProcess:1707): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 228 error_code 2 request_code 153 (GLX) minor_code 24)
  (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.)

(WebKitWebProcess:1730): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 212 error_code 2 request_code 153 (GLX) minor_code 24)
  (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.)

(WebKitWebProcess:1745): Gdk-ERROR **: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
  (Details: serial 212 error_code 2 request_code 153 (GLX) minor_code 24)
  (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.)

(In reply to Michael Catanzaro from comment #2)
> Thanks for taking the time to report this.
> Without a stack trace from the crash it's very hard to determine what caused
> it.
> Can you get us a stack trace? Please see
> https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces for
> more information on how to do so. When pasting a stack trace in this bug
> report, please reset the status of this bug report from NEEDINFO to its
> previous status. Thanks in advance!

I just update webkit-grk from 2.14.0 to 2.14.1
Recompile evolution-data-server-3.22.1 and evolution 3.22.1

Problem still exists :(

I make stack trace later

# export CFLAGS="-march=native -O2 -ggdb"
# export CXXFLAGS="${CFLAGS}"
compile evolution manually and install
gdb /usr/local/bin/evolutione
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from /usr/local/bin/evolution...done.

(gdb) set logging on
Copying output to gdb.txt.

(gdb) run
Starting program: /usr/local/bin/evolution
.......

ctrl+c
(gdb) thread apply all bt
retun, return, return... quit

Created attachment 338197 [details]
out.txt

Please take the backtrace with 'bt full' instead of just 'bt'. Also, and very importantly, don't Ctrl+C since we don't need a backtrace to your Ctrl+C, we need a backtrace to the X error. Just run Evolution normally and try to reproduce the error.

(gdb) set logging on
>> Copying output to gdb.txt.
(gdb) bt full
>> No stack.
(gdb) run
>> Starting program: /usr/local/bin/evolution

Evolution opened, http://i.imgur.com/mooAGYm.png

ctrl+c
(gdb) bt full


Right? Sorry for bad english

Created attachment 338198 [details]
gdb2.txt

Created attachment 338199 [details]
console.out

No Ctrl+C :)

I see the problem, you're running Evolution in gdb, but the Evolution process is not crashing. You need to get a backtrace from the WebKitWebProcess that is crashing. It's hard to get a backtrace for this manually. You should either use a distro bug report tool, like apport (Ubuntu) or ABRT (Fedora), or you should use coredumpctl: https://wiki.archlinux.org/index.php/Core_dump#Using_systemd

I find problem:
my nvidia-drivers have been updated, but I don't reload kernel module.
I stop X, rmmod/modprobe nvidia kernel module, start X and problem disapper.

sorry for bad english

OK then, no problem.

I have a reproducer, reliable (here), where the evolution crashes in an X error with the below backtrace. My steps are unusual for regular users, but maybe it'll shed some light on the issue.

I run evolution under gdb and press Ctrl+C do set my breakpoints and so on after it is loaded. As soon as do that I get the crash of the evolution as shown below. The backtrace mentions "WebKit::WebPageProxy::processDidCrash()", thus it looked like the WebKitWebPorcess crashed for some reason, thus I re-tried and I first attached another gdb to the running WebKitWebProcess and then repeated the Ctrl+C thing. It surprised me that the gdb of the WebKitWebProcess stopped too in the gdb prompt. I issues "c" command and everything went as it should. From that it seems to me that you pass really everything to the WebKitWebProcess, including the Ctrl+C, which just stops (crashes) the process when there is nothing on top of it, like gdb, which handles the interrupt request.

The backtrace on the evolution side with webkitgtk4-2.14.1-2.fc25.x86_64 (I'm sorry, no debug info for webkitgtk+, too large, but the steps should be better than the backtrace, I hope):

(gdb) bt

+ Trace 236771

Hm, I'm not so concerned about the processDidCrash signal... it's going to be triggered whenever the pipe to the web process is broken; I guess running under gdb could trigger that if one side is stalled for too long.

But the X error should never happen. It's odd that the reproducer requires gdb, but I think that's OK. Please go ahead and file a WebKit bug.

Okay, filled https://bugs.webkit.org/show_bug.cgi?id=164221