[SOLVED] Pan problem on -current

pchristy · 07-30-2019, 04:37 AM

I've been having this issue for quite a while, but only on one of the three machines running -current 64-bit with Eric's Plasma5.

The last version of pan that worked on this machine was 0.141. Every version since then has segfaulted - but only on this one machine! Up to now, I've stuck with 0.141, but that doesn't want to compile against the new gmime3, so now I have to try and find out what's wrong!

I have tried re-building pan, and it doesn't help. It compiles with no errors, but still segfaults immediately on running.

Running from a terminal just says that it segfaults. Running the stock version of 0.145 through gdb (no debugging symbols) gives:

Code:

Reading symbols from /usr/bin/pan...
(No debugging symbols found in /usr/bin/pan)
(gdb) run
Starting program: /usr/bin/pan 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff3b6e700 (LWP 2997)]
[New Thread 0x7fffebfff700 (LWP 2998)]
[New Thread 0x7ffff336d700 (LWP 2999)]
[New Thread 0x7ffff2b6c700 (LWP 3000)]
[New Thread 0x7ffff1aa4700 (LWP 3001)]
[New Thread 0x7ffff12a3700 (LWP 3002)]

Thread 1 "pan" received signal SIGSEGV, Segmentation fault.
0x00007ffff6130d10 in __strftime_internal () from /lib64/libc.so.6

libc.so.6 is a symlink to libc-2.29.so.

This doesn't mean much to me as I'm not a programmer, but before I recompile it with debugging enabled, I thought I'd ask here for any ideas.

Cheers,

--
Pete

Labinnah · 07-30-2019, 05:27 AM

You have already LQ thread about this issue. You should continue there.
https://www.linuxquestions.org/quest...nt-4175619184/

You even create bug report in pan bugzilla. If you look closely there you will see that they made fix for this.
https://gitlab.gnome.org/GNOME/pan/issues/77

pchristy · 07-30-2019, 05:36 AM

Thanks for the reply, but this seems to be a separate issue. Subsequent updates in -current fixed the problem on two machines that were complaining about gmime3, but it hasn't fixed the problem on the 3rd, which seems to be complaining about libc.so.6.

As far as I am aware, all three machines are running similar installs, except for minor differences in the processors (AMD or Intel).

Looks like I'll have to recompile with debugging enabled....

Labinnah · 07-30-2019, 06:37 AM

But it look same. Take a look at your previous traces, it also crash at "__strftime_internal".

pchristy · 07-30-2019, 08:36 AM

Yes, but originally it was happening on three machines - now its only on one! Clearly something is different. The workaround I have been using no longer works.

Labinnah · 07-30-2019, 08:56 AM

As this function is date related, different may be many things not related with physical computer, but i.e. with currently fetched news (and its dates).

And why you need workaround? In this bug report is patch for this issue.

pchristy · 07-30-2019, 09:06 AM

Quote:

Originally Posted by Labinnah

And why you need workaround? In this bug report is patch for this issue.

Which worked on two machines, but not on the third (my main) machine.

Labinnah · 07-30-2019, 10:21 AM

OK. I'm looking closely to pan source around this "strftime", and see no reason how patch from bugzilla can helps in this situation.

Unfortunately strftime (file pan/general/e-util.cc) takes 3 pointer arguments, and any of them can cause problems.

Code:

static size_t
e_strftime(char *s, size_t max, const char *fmt, const struct tm *tm)
{
#ifdef HAVE_LKSTRFTIME
	return strftime(s, max, fmt, tm);
#else
	char *c, *ffmt, *ff;
	size_t ret;

	ffmt = g_strdup(fmt);
	ff = ffmt;
	while ((c = strstr(ff, "%l")) != NULL) {
		c[1] = 'I';
		ff = c;
	}

	ff = ffmt;
	while ((c = strstr(ff, "%k")) != NULL) {
		c[1] = 'H';
		ff = c;
	}

	ret = strftime(s, max, ffmt, tm);
	g_free(ffmt);
	return ret;
#endif
}

Assumption #1
Buffer "s" is shorter than "max" bytes.
This is unlikely, at higher level max is set to sizeof(s). However, if you want you can try change, in "EvolutionDateMaker :: get_date_string (time_t then_time)"

Code:

  struct tm then_tm;
  char buf[100]; // to char buf[200];
  char *temp;

or in ALL calls to e_utf8_strftime_fix_am_pm

Code:

  if (now_time - then_time < 60 * 60 * 8 && now_time > then_time) {
    e_utf8_strftime_fix_am_pm (buf, sizeof(buf), locale_recent, &then_tm); // to e_utf8_strftime_fix_am_pm (buf, sizeof(buf) - 1, locale_recent, &then_tm);
    done = true;
  }

Assumption #2
tm is NULL
Almost impossible tm is pointer to automatic variable some levels higher

Assumption #3
fmt is NULL
This is possible. Format string are taken from here:

Code:

EvolutionDateMaker :: EvolutionDateMaker (time_t now)
{
  // build the locale strings
  locale_recent = g_locale_from_utf8 (_("%l∶%M %p"), -1, NULL, NULL, NULL);
  locale_today = g_locale_from_utf8 (_("Today %l∶%M %p"), -1, NULL, NULL, NULL);
  locale_this_week = g_locale_from_utf8 (_("%a %l∶%M %p"), -1, NULL, NULL, NULL);
  locale_this_year = g_locale_from_utf8 (_("%b %d %l∶%M %p"), -1, NULL, NULL, NULL);
  locale_old = g_locale_from_utf8 (_("%b %d %Y"), -1, NULL, NULL, NULL);

Return values from "g_locale_from_utf8" are not checked for NULL. But they can be NULL since this are translatable strings and some translator can make error in string encoding. Even this strings can make problems since they are itself utf-8 encoded, and when compiled in non utf-8 environment may create unreadable garbage and "g_locale_from_utf8" returns error (NULL).

You can try this option by running pan in different locale i.e.

Code:

LANG=C pan
LANG=en_US.utf-8 pan
LANG=en_GB.utf-8 pan

pchristy · 07-30-2019, 10:33 AM

Wow! That worked! LANG=C caused the segfault, but using either en_US or en_GB allowed it to run! I'm in the UK, so en_GB is the most appropriate!

There doesn't seem to be an option to select the language in pan anywhere, so I need to dig a little and find out where to set that option permanently! (I have LANG=en_GB set in profile.d/lang.sh - maybe it needs the utf-8 added?)

Thank you so much! This problem has been bugging me for ages!

--
Pete

Labinnah · 07-30-2019, 10:37 AM

Better continue your bug report, and notify pan developers about it. Let them fixed this problem permanently.

pchristy · 07-30-2019, 10:53 AM

Sorry, cross-posted! I was editing my last post when you replied!

When I checked, I had set LANG=en_GB in /etc/profile.d/lang.sh. Changing it to en_GB.utf-8 has got pan working again.

I knew it had to be something unique to that machine, and guessed it was probably something I'd done, but I would never have found that typo without your help! Again, many thanks!

--
Pete