2:12 p.m.
Sent: Tuesday, September 19, 2017 at 9:13 PM
From: "Daniel Wagner" <wagi(a)monom.org>
To: "Cliff McDiarmid" <cliffhanger(a)gardener.com>, connman(a)lists.01.org
Subject: Re: Connman coredump
Hi Cliff,
I think the last message was unreadable, I'm sending again.
On 09/17/2017 03:04 PM, Cliff McDiarmid wrote:
Hi
Must apologize for other unconnected emails that have dropped in
forum. Still trying to figure how that occured.
I've been using Connman for about three years and have had nothing
but success.
That nice to hear :)
But I've just installed into a Gnome3 64bit systemd system.
I'm
now experiencing dumps every five minutes or so,
Do you happen to get a stack trace?
No
after restarting the
connection, into /var/lib/connman. These consist of sizable files
labelled 'stats-918J6Y', as an example, of up to a gig in size.
There is nothing obvious from the journal log, but maybe the
following?
Is there something in the connman log (journald -u connman.service)?
If
not you could also start connman with the debug option and not in the
background (-d -n); that is without systemd.
Started Connman manually from the command line with debug option with the output to a log
file.
it crashed and produced a 'stats' file. It needs someone clever than me to
interpret it.
The log file is attached.
thanks Daniel
12:20 p.m.
Hi Cliff,
[...]
connmand[3059]: wlp2s0 {RX} 552 packets 168100 bytes
connmand[3059]: wlp2s0 {TX} 190 packets 25492 bytes
connmand[3059]: src/ipconfig.c:update_stats() service 0x136fb50
connmand[3059]: src/service.c:stats_update() service 0x136fb50
connmand[3059]: src/stats.c:__connman_stats_update() ring buffer is full, update history
file
When the buffer is full, ConnMan creates a summary and adds it
to the history file.
connmand[3059]: src/stats.c:stats_open() file 0x7ffe2ee42030 name
/var/lib/connman/wifi_002710c99f58_544e434150453238313037_managed_psk/history
connmand[3059]: src/stats.c:stats_file_setup() file 0x7ffe2ee42030 fd 23 name
/var/lib/connman/wifi_002710c99f58_544e434150453238313037_managed_psk/history
connmand[3059]: src/stats.c:stats_file_remap() file 0x7ffe2ee42030 size 4096
addr (nil) len 0
connmand[3059]: src/stats.c:stats_file_setup() file 0x7ffe2ee42090 fd 24 name
/var/lib/connman/stats.MGTZ6Y.tmp
connmand[3059]: src/stats.c:stats_file_remap() file 0x7ffe2ee42090 size 4096
addr (nil) len 0
So this looks still okay. The first remap is the history file open (empty
file), the secon remap is a the temporay new history file (also empty).
(connmand:3059): GLib-CRITICAL **: g_date_set_time_t: assertion
'g_date_valid_dmy (date->day, date->month, date->year)' failed
(connmand:3059): GLib-CRITICAL **: g_date_compare: assertion 'g_date_valid
(lhs)' failed
(connmand:3059): GLib-CRITICAL **: g_date_days_between: assertion 'g_date_valid
(d1)' failed
(connmand:3059): GLib-CRITICAL **: g_date_set_time_t: assertion
'g_date_valid_dmy (date->day, date->month, date->year)' failed
(connmand:3059): GLib-CRITICAL **: g_date_set_time_t: assertion
'g_date_valid_dmy (date->day, date->month, date->year)' failed
(connmand:3059): GLib-CRITICAL **: g_date_update_julian: assertion
'g_date_valid_dmy (d->day, d->month, d->year)' failed
[...]
The corresponding code to those glib critical message is:
static int summarize(struct stats_file *data_file,
struct stats_file *history_file,
struct stats_file *temp_file)
{
struct stats_iter data_iter;
struct stats_iter history_iter;
struct stats_record *cur, *next;
GDate today, date_change_step_size;
/*
* First calculate the date when switch from monthly
* accounting period size to daily size
*/
g_date_set_time_t(&today, time(NULL));
date_change_step_size = today;
if (g_date_get_day(&today) - data_file->account_period_offset >= 0)
g_date_subtract_months(&date_change_step_size, 2);
else
g_date_subtract_months(&date_change_step_size, 3);
g_date_set_day(&date_change_step_size,
data_file->account_period_offset);
Since the first glib message is about g_data_set_time_t(), it could be that
glib is not happy with the timezone settings.
https://developer.gnome.org/glib/stable/glib-Date-and-Time-Functions.html...
g_data_set_time_t() calls g_date_valid_dmy eventually which is pretty unhappy:
/**
* g_date_valid_dmy:
* @day: day
* @month: month
* @year: year
*
* Returns %TRUE if the day-month-year triplet forms a valid, existing day
* in the range of days #GDate understands (Year 1 or later, no more than
* a few thousand years in the future).
*
* Returns: %TRUE if the date is a valid one
*/
gboolean
g_date_valid_dmy (GDateDay d,
GDateMonth m,
GDateYear y)
{
return ( (m > G_DATE_BAD_MONTH) &&
(m < 13) &&
(d > G_DATE_BAD_DAY) &&
(y > G_DATE_BAD_YEAR) && /* must check before using
g_date_is_leap_year */
(d <= (g_date_is_leap_year (y) ?
days_in_months[1][m] : days_in_months[0][m])) );
}
Can you check if your time settings are correct on your platform?
Thanks,
Daniel
1215
days inactive
1216
days old
1 comments
2 participants
participants (2)
-
Cliff McDiarmid -
Daniel Wagner