Shell producing storms of 4000+ "Value 18446744073709551615 cannot be safely stored in a JS number" journal messages
I already reported this in Fedora's bugzilla (rhbz 1668827), but I wanted to reproduce it here as well.
For at least the past several months, my desktop (an HP system currently running Fedora 29 x86_64) has been plagued by storms of journal messages coming from gnome-shell
at irregular intervals, several times per day on average.
Each occurrence takes the form of the gnome-shell
process outputting the same message thousands of times (currently, exactly 4091 each time) over the course of only a second or two. These storms cause no apparent impact other than to fill up my journal, so they're merely annoying, not a problem.
The exact contents of the message are:
$ journalctl --user -b|grep "cannot be safely stored" |tail -n5 |fmt -s
Jan 23 07:37:22 teevey gnome-shell[2114]: Value 18446744073709551615
cannot be safely stored in a JS Number and may be rounded
Jan 23 07:37:22 teevey gnome-shell[2114]: Value 18446744073709551615
cannot be safely stored in a JS Number and may be rounded
Jan 23 07:37:22 teevey gnome-shell[2114]: Value 18446744073709551615
cannot be safely stored in a JS Number and may be rounded
Jan 23 07:37:22 teevey gnome-shell[2114]: Value 18446744073709551615
cannot be safely stored in a JS Number and may be rounded
Jan 23 07:37:22 teevey gnome-shell[2114]: Value 18446744073709551615
cannot be safely stored in a JS Number and may be rounded
Same message, same value, every time.
The exact message in question only exists in one place (across the entirety of the internet, as far as I can tell). The gjs source file gi/arg.cpp
contains a gjs_value_from_g_argument()
function, which since gjs@048fceed will output that message when supplied with a 64-bit signed or unsigned integer larger than MAX_SAFE_INT64
.
https://gitlab.gnome.org/GNOME/gjs/blob/master/gi/arg.cpp#L2728-2741
case GI_TYPE_TAG_INT64:
if (arg->v_int64 == G_MININT64 ||
std::abs(arg->v_int64) > MAX_SAFE_INT64)
g_warning("Value %" G_GINT64_FORMAT " cannot be safely stored in "
"a JS Number and may be rounded", arg->v_int64);
value_p.setNumber(static_cast<double>(arg->v_int64));
break;
case GI_TYPE_TAG_UINT64:
if (arg->v_uint64 > MAX_SAFE_INT64)
g_warning("Value %" G_GUINT64_FORMAT " cannot be safely stored in "
"a JS Number and may be rounded", arg->v_uint64);
value_p.setNumber(static_cast<double>(arg->v_uint64));
break;
But as for why gnome-shell
occasionally passes the value 18446744073709551615 into that function thousands of times? Search me. I have no idea what's generating the messages, or what's triggering the storms. I don't see any obvious pattern relating it to any particular user actions on my part, but I can't rule out the possibility either.
As I said, currently each occurrence of the issue outputs that message exactly 4091 times. However, the problem goes back at least several months on my machine, and the storms USED to involve smaller numbers of repetitions.
storm-counts.txt Attached is the output of the following command:
journalctl --user |grep "cannot be safely stored" |cut -c1-14|uniq -c
It thus contains 385 lines, going back to October 19 2018 (the beginning of my available user journal history), like the following:
3250 Oct 19 18:06:3
3250 Oct 19 18:43:1
3250 Oct 19 21:32:3
(A storm of 3250 messages at 18:06, again at 18:45, again at 21:23)
The repetition counts varied somewhat under Fedora 28 / GNOME Shell 3.28 (at the time) — sometimes 3000, sometimes only 1000, sometimes 2750. Always very round numbers, though.
Then, at this* exact point, the counts stabilized, and every time since it has been 4091 lines exactly:
445 Nov 08 05:01:5
932 Nov 08 05:08:3
445 Nov 08 05:09:4
1000 Nov 08 07:28:1
913 Nov 08 11:10:0
1000 Nov 08 23:32:2
1000 Nov 09 02:58:1
1000 Nov 09 08:08:3
1000 Nov 09 18:09:2
4091 Nov 09 21:25:3 <-- *Right here
4091 Nov 09 22:01:4
4091 Nov 10 02:01:1
2946 Nov 10 03:36:2 \ (single storm,
1145 Nov 10 03:36:3 / sums to 4091)
4091 Nov 10 06:15:4
4091 Nov 10 11:26:5
4091 Nov 10 14:39:3
November 9 was the day I upgraded the system to Fedora 29 / GNOME Shell 3.30.1-2.fc29.x86_64
, and 21:25 is just four minutes after the system booted following the completion of the dnf system-upgrade reboot
upgrade process.