[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 b

From: Mark Dymek
Subject: Re: [Pan-users] segmentation fault trying to use Pan 0.146, including backtrace
Date: Wed, 04 Dec 2019 18:41:12 -0500
User-agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1


On Sun, Dec 1, 2019, at 9:29 AM, Julien Michielsen wrote:
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
> 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
#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 
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 
const*, std::allocator<pan::DataImpl::ArticleNode const*> > const&) 
(this=this@entry=0x555556626de0, candidates=std::vector of length 1, 
capacity 1 = {...}) at
#9  0x0000555555675d8d in 
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 
#19 0x00007ffff6831650 in  () at 
#20 0x00007ffff6831962 in g_main_loop_run () at 
#21 0x00007ffff78c2a37 in gtk_main () at 
#22 0x00005555555bea6d in (anonymous namespace)::run_pan_in_window 
     ..., 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
> 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 Michielsen

Pan-users mailing list

reply via email to

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