Pan problem on -current
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... 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 |
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 |
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.... |
But it look same. Take a look at your previous traces, it also crash at "__strftime_internal".
|
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.
|
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. |
Quote:
|
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 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; Code:
if (now_time - then_time < 60 * 60 * 8 && now_time > then_time) { 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) You can try this option by running pan in different locale i.e. Code:
LANG=C pan |
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 |
Better continue your bug report, and notify pan developers about it. Let them fixed this problem permanently.
|
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 |
All times are GMT -5. The time now is 02:19 AM. |