Re: [Pan-users] segmentation fault trying to use Pan 0.146, including backtrace

[Julien Michielsen]

Per Hedeland schreef op 01-12-2019 14:41:
> On 2019-12-01 14:07, Julien Michielsen wrote:
> > I compiled and installed the latest Pan because I continued
> > to get a segmentation fault with the "standard Pan 0.144"
> > that came with Ubuntu 18.0.4.  No help: I still get the same
> > error message, with the same announcement.  I ran the program
> > under gdb and got the following output:
> >
> > Starting program: /usr/local/bin/pan
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library 
> > "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > [New Thread 0x7fffec030700 (LWP 11360)]
> > [New Thread 0x7fffeb82f700 (LWP 11361)]
> > [New Thread 0x7fffeb02e700 (LWP 11362)]
> > [New Thread 0x7fffea82d700 (LWP 11363)]
> > [New Thread 0x7fffe93b9700 (LWP 11364)]
> > [New Thread 0x7fffe8bb8700 (LWP 11365)]
> > [New Thread 0x7fffd3fff700 (LWP 11366)]
> > [New Thread 0x7fffd37fe700 (LWP 11367)]
> > [Thread 0x7fffd37fe700 (LWP 11367) exited]
> > [Thread 0x7fffd3fff700 (LWP 11366) exited]
> >
> > Thread 1 "pan" received signal SIGSEGV, Segmentation fault.
> > __strftime_internal (s=0x7fffffffbb30 "@\033\271\365\377\177", 
> > maxsize=100, format=0x0, tp=0x7fffffffbaf0,
> >      tzset_called=tzset_called@entry=0x7fffffffba97, 
> > loc=0x7ffff5b95560 <_nl_global_locale>) at strftime_l.c:560
> > 560    strftime_l.c: No such file or directory.
> >
> > I also asked for a backtrace, and got the output from it,
> > but don't think this is usefull for this list.
>
> I don't know why it wouldn't be - I don't think there is a dedicated
> "developer" list.
>
> > If this output
> > would be welcome to someone, I'll be happy to supply it.
>
> Please do. The crash is likely caused by the 'format=0x0' argument, it
> should be (a pointer to) a format string for strftime_l(), see the
> strftime(3) man page. The full backtrace might explain how this came
> about.
Thanks Per, for your willingness to dive into my problem, and also
to tell what information I should supply. The backtrace comes below:

(gdb) -b# ## #backtrace
#0  0x00007ffff5882e5b in __strftime_internal (s=0x7fffffffbb30 
"@\033\271\365\377\177", maxsize=100, format=0x0, tp=0x7fffffffbaf0, 
tzset_called=tzset_called@entry=0x7fffffffba97, loc=0x7ffff5b95560 
<_nl_global_locale>) at strftime_l.c:560
#1  0x00007ffff5885266 in __GI___strftime_l (s=<optimized out>, 
maxsize=<optimized out>, format=<optimized out>, tp=<optimized out>, 
loc=<optimized out>) at strftime_l.c:460
#2  0x00005555556db2e3 in 
EvolutionDateMaker::e_utf8_strftime_fix_am_pm(char*, unsigned long, char 
const*, tm const*) const (this=this@entry=0x7fffffffbd90, 
s=s@entry=0x7fffffffbb30 "@\033\271\365\377\177", max=max@entry=100, 
locale_fmt=<optimized out>, tm=tm@entry=0x7fffffffbaf0) at e-util.cc:170
#3  0x00005555556db75f in EvolutionDateMaker::get_date_string(long) 
const (this=this@entry=0x7fffffffbd90, then_time=<optimized out>) at 
e-util.cc:282
#4  0x00005555555f57ee in pan::HeaderPane::create_row(EvolutionDateMaker 
const&, pan::Article const*) (this=this@entry=0x555555a59400, e=..., 
a=0x5555566ed9d0) at header-pane.cc:429
#5  0x00005555555f75a9 in 
pan::HeaderPane::on_tree_change(pan::Data::ArticleTree::Diffs const&) 
(this=0x555555a59400, diffs=...) at header-pane.cc:831
#6  0x00005555556741a1 in 
pan::Data::ArticleTree::fire_diffs(pan::Data::ArticleTree::Diffs const&) 
const (d=..., this=0x555556626de0) at ../../pan/data/data.h:539
#7  0x00005555556741a1 in 
pan::DataImpl::MyTree::add_articles(std::vector<pan::DataImpl::ArticleNode 
const*, std::allocator<pan::DataImpl::ArticleNode const*> > const&) 
(this=this@entry=0x555556626de0, nodes_in=std::vector of length 1, 
capacity 1 = {...}) at my-tree.cc:674
#8  0x0000555555674f79 in 
pan::DataImpl::MyTree::apply_filter(std::vector<pan::DataImpl::ArticleNode 
const*, std::allocator<pan::DataImpl::ArticleNode const*> > const&) 
(this=this@entry=0x555556626de0, candidates=std::vector of length 1, 
capacity 1 = {...}) at my-tree.cc:368
#9  0x0000555555675d8d in 
pan::DataImpl::MyTree::add_articles(std::set<pan::Quark, 
std::less<pan::Quark>, std::allocator<pan::Quark> > const&) 
(this=0x555556626de0, mids=std::set with 1 element = {...})
    at my-tree.cc:490
#10 0x000055555565dd7c in pan::DataImpl::on_articles_added(pan::Quark 
const&, std::set<pan::Quark, std::less<pan::Quark>, 
std::allocator<pan::Quark> > const&) (this=this@entry=0x7fffffffd570, 
group=..., mids=std::set with 1 element = {...}) at headers.cc:1199
#11 0x000055555567967a in pan::DataImpl::xover_flush(pan::Quark const&) 
(this=0x7fffffffd570, group=...)
    at xover.cc:194
#12 0x000055555567a36f in pan::DataImpl::xover_add(pan::Quark const&, 
pan::Quark const&, pan::StringView const&, pan::StringView const&, long, 
pan::StringView const&, pan::StringView const&, unsigned long, unsigned 
long, pan::StringView const&, bool) (this=this@entry=0x7fffffffd570, 
server=..., group=..., subject=..., a---Type <return> to continue, or q 
<return> to quit---
uthor=..., time_posted=time_posted@entry=1574617470, message_id=..., 
references_in=..., byte_count=3180, line_count=40, xref=..., 
is_virtual=false) at xover.cc:331
#13 0x000055555568c25e in 
pan::TaskXOver::on_nntp_line_process(pan::NNTP*, pan::StringView const&) 
(this=this@entry=0x555555ebed70, nntp=<optimized out>, 
nntp@entry=0x5555566c4010, line=...) at task-xover.cc:421
#14 0x000055555568c816 in pan::TaskXOver::on_nntp_line(pan::NNTP*, 
pan::StringView const&) (this=0x555555ebed70, nntp=0x5555566c4010, 
line=...) at task-xover.cc:310
#15 0x000055555569756a in pan::NNTP::on_socket_response(pan::Socket*, 
pan::StringView const&) (this=0x5555566c4010, sock=<optimized out>, 
line_in=...) at nntp.cc:102
#16 0x00005555556aee42 in pan::GIOChannelSocket::do_read() 
(this=0x7fffe4001340) at socket-impl-gio.cc:346
#17 0x00005555556aff05 in pan::GIOChannelSocket::gio_func(_GIOChannel*, 
GIOCondition) (this=0x7fffe4001340, channel=<optimized out>, 
cond=<optimized out>) at socket-impl-gio.cc:457
#18 0x00007ffff6831285 in g_main_context_dispatch () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff6831650 in  () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#20 0x00007ffff6831962 in g_main_loop_run () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#21 0x00007ffff78c2a37 in gtk_main () at 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#22 0x00005555555bea6d in (anonymous namespace)::run_pan_in_window 
(group_prefs=
    ..., window=0x555555e9a0d0, prefs=..., queue=..., data=..., 
_gui=0x555555a59e90) at pan.cc:562
#23 0x00005555555bea6d in main(int, char**) (argc=<optimized out>, 
argv=<optimized out>) at pan.cc:1128
(gdb) quit
A debugging session is active.

        Inferior 1 [process 15894] will be killed.

Quit anyway? (y or n) y

> > I looked if the file strftime_l.c resides on my computer, but
> > it doesn't.
>
> This isn't the problem, it's just gdb that tries to print out the
> relevant source code lines, and reports that it can't since you don't
> have the source (in a place where gdb can find it). I googled
> strftime_l.c, and the first hit was a glibc version at
> https://code.woboq.org/userspace/glibc/time/strftime_l.c.html - and it
> seems it is even the right version (probably doesn't change much),
> line 560 is:
>
>   for (f = format; *f != '\0'; ++f)
>
> This will indeed cause a segfault due to the *f dereference if format
> is 0/NULL.
>
> > Does anyone have a hint how to get this running?
>
> Not me - FWIW, Pan 0.145 works fine for me on FreeBSD. It may be
> something specific to your environment. Does it crash immediately on
> startup, i.e. doesn't even display a window? If not, how far does it
> get?

Pan starts up, and shows the groups available on the site. It allows
me to search for a sepicific newsgroup, but abandons at the time of
loading that group, and gives the segmentation fault.
Thanks again
Julien
--
Julien Michielsen
address@hidden