[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Julien Michielsen
Subject: Re: [Pan-users] segmentation fault trying to use Pan 0.146, including backtrace
Date: Sun, 01 Dec 2019 15:29:22 +0100
User-agent: XS4ALL Webmail

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/".
[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

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 #3 0x00005555556db75f in EvolutionDateMaker::get_date_string(long) const (this=this@entry=0x7fffffffbd90, then_time=<optimized out>) at #4 0x00005555555f57ee in pan::HeaderPane::create_row(EvolutionDateMaker const&, pan::Article const*) (this=this@entry=0x555555a59400, e=..., a=0x5555566ed9d0) at #5 0x00005555555f75a9 in pan::HeaderPane::on_tree_change(pan::Data::ArticleTree::Diffs const&) (this=0x555555a59400, diffs=...) at #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 #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 #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 = {...})
#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 #11 0x000055555567967a in pan::DataImpl::xover_flush(pan::Quark const&) (this=0x7fffffffd570, group=...)
#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 #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 #14 0x000055555568c816 in pan::TaskXOver::on_nntp_line(pan::NNTP*, pan::StringView const&) (this=0x555555ebed70, nntp=0x5555566c4010, line=...) at #15 0x000055555569756a in pan::NNTP::on_socket_response(pan::Socket*, pan::StringView const&) (this=0x5555566c4010, sock=<optimized out>, line_in=...) at #16 0x00005555556aee42 in pan::GIOChannelSocket::do_read() (this=0x7fffe4001340) at #17 0x00005555556aff05 in pan::GIOChannelSocket::gio_func(_GIOChannel*, GIOCondition) (this=0x7fffe4001340, channel=<optimized out>, cond=<optimized out>) at #18 0x00007ffff6831285 in g_main_context_dispatch () at /usr/lib/x86_64-linux-gnu/ #19 0x00007ffff6831650 in () at /usr/lib/x86_64-linux-gnu/ #20 0x00007ffff6831962 in g_main_loop_run () at /usr/lib/x86_64-linux-gnu/ #21 0x00007ffff78c2a37 in gtk_main () at /usr/lib/x86_64-linux-gnu/ #22 0x00005555555bea6d in (anonymous namespace)::run_pan_in_window (group_prefs= ..., window=0x555555e9a0d0, prefs=..., queue=..., data=..., _gui=0x555555a59e90) at #23 0x00005555555bea6d in main(int, char**) (argc=<optimized out>, argv=<optimized out>) at
(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 - 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

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 Michielsen

reply via email to

[Prev in Thread] Current Thread [Next in Thread]