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
_______________________________________________
Pan-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/pan-users