Stats module of Jetpack causing core dump file

Could you add the following to your site’s wp-config.php file?

define('WP_DEBUG', true);

if ( WP_DEBUG ) {

        @error_reporting( E_ALL );
        @ini_set( 'log_errors', true );
        @ini_set( 'log_errors_max_len', '0' );

        define( 'WP_DEBUG_LOG', true );
        define('WP_DEBUG_DISPLAY', false);
        define( 'CONCATENATE_SCRIPTS', false );
        define( 'SAVEQUERIES', true );

}

Once you’ve done so, try to activate Jetpack Stats again, and then check the wp-content/debug.log file for errors. You can paste the results here. You can then replace define('WP_DEBUG', true); by define('WP_DEBUG', false); in the code above.

Thanks!

Thanks. I have just added the code to the wp-config.php file. I will be waiting for the next occurrence of the crash event to collect some data. It occurs several times in a day but I did not find any way to reproduce the bug sistematically.

Hello, I have got 3 occurrences of core.xxx file but any debug file have been created into wp-content folder. It is possible that the process crashes before than having the ability to create the log file. Is there any way to increase the verbosity level of the plugin, to track any function called?
Thanks,
Emanuele

PS: like you asked, I changed the wp-config.php file, then deactivated, reactivated and connected to Wp again Jetpack.

If everything crashes before anything gets written to the debug.log file, could you check yu server error logs, and let me know if you get useful information there?

Thanks!

No, unfortunately nothing appears into the error_log file. I have customized my php.ini file to collect all error_log around my hosting space into one only file but nothing happens.
I have asked for some Apache log to my Hosting provider but they didn’t find anything relevant in there (I still have a ticket open with them).
Thanks,
Emanuele

That’s intesresting. It might be worth asking your hosting provider to check one of the core dumps to find out more. With a tool like gdb, they should be able to investigate further, or backtrace the issue to its exact cause.

Let me know what they find!

I have already analyzed the core dump file with gdb. This is the report of one core dump file:

——————–
GNU gdb (GDB) Red Hat Enterprise Linux (7.2-83.el6)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i686-redhat-linux-gnu”.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/&gt;.
Missing separate debuginfo for the main executable file
Try: yum –enablerepo=’*-debug*’ install /usr/lib/debug/.build-id/da/a2b1f6b7a3d22eb979147c3810b8b8a0740650
[New Thread 31016]
Core was generated by `/usr/bin/php /home/pixel8383/public_html/dreamsworld/emanuele/index.php’.
Program terminated with signal 11, Segmentation fault.
#0 0x083e5ed6 in ?? ()
(gdb)
——————–

Thanks to it I was able to locate the issue into my WordPress installation.
I then – in order – did the following:
1. disable all the plugin and reactivate one by one to discover which one was bugged.
2. reinstall WordPress (via FTP, I deleted and re-installed everything into the /wp-includes, /wp-admin and / folder).
3. reinstall Akismet and Jetpack (both via FTP to be sure that everything was deleted).

After several days I was able to discover that the core dumps were generated when the Stats module inside Jetpack was active. If I disable that module the issue disappear.
I am using WordPress (and Jetpack) since its earlier versions and since I have auto-update feature enabled I suppose the issue has been introduced into the latest versions…

If you think it could be helpful, I could link here one core dump file.

Thanks for the extra details.

Could you send us the core dump file via this contact form:
https://jetpack.com/contact-support/

It might also help if you could try to install a previous version of Jetpack, and see if the problem persists.

Thanks!

Jeremy thanks for your support. I have sent a core dump file to Lisa, I hope she will soon forward it to you. Yesterday I tried the latest release of Jetpack with no success. I will soon test an older version. Do you have any suggestion about the version to install?
Thanks,
Emanuele

I will soon test an older version. Do you have any suggestion about the version to install?

I’m afraid I can’t really tell without knowing more about what’s causing the issue. We’ll take a look at the file you sent us and get back to you soon!

This is not a good news. I tried to install Jetpack 3.4.3 (and deactivated auto-update function on WordPress.com). Unfortunately after a few hours I got a new core.xxx file. I don’t know what else to do. Did you discovered something useful inside the dump file?
Thanks,
Emanuele

Did one of my colleagues get back to you already? If not, do not hesitate to send them a new email!

No answer yet. I will try to answer to Lisa again… in the meanwhile my hosting provider – kindly – gave me a new account on a different machine to do some testing and check if the issue is not server side.
Thanks,
Emanuele

Jeremy, just to keep the post updated: maybe I found the location of the issue and it could be outside of Jetpack plugin.
This morning, while trying to figure out something new, I checked Google’s webmasters tool page. I didn’t think of it during these days. Since we couldn’t get any error_log, maybe Google was recording the pages involved somehow.
Well… I discovered that an Audio Player plugin (https://www.ads-software.com/tags/audio-player which now seems to be dismissed) was causing 500 errors on pages with audio files. 46 pages on thousand. I deleted the plugin and changed the code to embed the file (now using the all new [embed] tag instead of the [audio] tag implemented into that plugin). Now those 46 pages are back online again without errors. I cannot believe it was so easy and I can’t still understand how it was possible that I got core.dump file even when the plugin was deactivated.
Maybe some cached pages?
Or… maybe Jetpack has some functionality to evaluate [audio] tags?
The code causing those 500 errors was the following:
<p align="center">[audio:file.mp3]</p>
Now it is:
<div align="center">[embed]https://path/to/file.mp3[/embed]</div>
I will keep on eye my root folder to see if new core dump files are generated but I have great hopes that this was the reason.

Emanuele

Glad to hear you figured it out!

maybe Jetpack has some functionality to evaluate [audio] tags?

It used to, but we removed that functionality when the [audio] shortcode was added to WordPress a few releases ago. WordPress itself might have been choking on this wrongly formatted shortcode, though.

Let us know how it goes.