newsboat 2.36 coredumps on exit on 14.1-RELEASE

I

igork

Hi;

I installed newsboat from the packages.

$ pkg install newsboat

When I run it, it opens up with the feeds screen. I can navigate/read
feeds. All looks good. When I hit the 'q' key to exit newsboat, it
coredumps, and I see this output

Code: 
Cleaning up cache...done.
Illegal instruction (core dumped)

and the newsboat.core file in the working directory.

Code: 
$ uname -a
FreeBSD forum.technicolor 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 GENERIC amd64
Code: 
$ pkg version -n newsboat
newsboat-2.36_2                    =

My CPU is AMD Ryzen 7 7735HS with Radeon Graphics (3194.11-MHz K8-class CPU)

And backtrace shows this

Code: 
$ lldb -c newsboat.core /usr/local/bin/newsboat
(lldb) bt
* thread #1, name = 'newsboat', stop reason = signal SIGILL
  * frame #0: 0x000000082a5bf62f libc++.so.1`std::__1::recursive_mutex::~recursive_mutex() + 15
    frame #1: 0x00000000002e33af newsboat`newsboat::Controller::~Controller(this=0x0000000820fce9f8) at controller.cpp:95:2
    frame #2: 0x00000000002ba1b8 newsboat`main(argc=1, argv=<unavailable>) at newsboat.cpp:316:1
    frame #3: 0x000000082cac9a6a libc.so.7`__libc_start1 + 298
    frame #4: 0x00000000002b6980 newsboat`_start at crt1_s.S:83

I'm curious what and why this is happening.

Now, I'm trying to build newsboat from the ports and see if that makes it different.
 
Last edited by a moderator:
I've built the newsboat from ports, same version (the ports on branch 2024Q4),
with debug symbols (make WITH_DEBUG=1). Getting the same coredump behavior.

Using debugger I could proceed to this

Code: 
$ lldb -p `pgrep newsboat`
(lldb) process attach --pid 3675
Process 3675 stopped
* thread #1, name = 'newsboat', stop reason = signal SIGSTOP
    frame #0: 0x000000082d8894ea libc.so.7`__sys_poll + 10
libc.so.7`__sys_poll:
->  0x82d8894ea <+10>: jb     0x82d886268
    0x82d8894f0 <+16>: retq   
    0x82d8894f1:       int3   
    0x82d8894f2:       int3   
  thread #2, name = 'newsboat', stop reason = signal SIGSTOP
    frame #0: 0x000000082d88946a libc.so.7`__sys_nanosleep + 10
libc.so.7`__sys_nanosleep:
->  0x82d88946a <+10>: jb     0x82d886268
    0x82d889470 <+16>: retq   
    0x82d889471:       int3   
    0x82d889472:       int3
Executable module set to "/usr/local/bin/newsboat".
Architecture set to: x86_64-unknown-freebsd14.1.
(lldb) c
Process 3675 resuming
(lldb) b newsboat`newsboat::Controller::~Controller
Breakpoint 1: where = newsboat`newsboat::Controller::~Controller() + 14 at controller.cpp:95:9, address = 0x00000000002e320e
Process 3675 stopped
* thread #1, name = 'newsboat', stop reason = breakpoint 1.1
    frame #0: 0x00000000002e320e newsboat`newsboat::Controller::~Controller(this=0x0000000820f64608) at controller.cpp:95:9
   92    
   93    Controller::~Controller()
   94    {
-> 95            delete rsscache;
   96            delete urlcfg;
   97            delete api;
   98    }
(lldb) p rsscache
(newsboat::Cache *) 0x00003fa4a36d5800
(lldb) p *rsscache
(newsboat::Cache) {
  db = 0x00003fa4a36ed000
  cfg = 0x0000000820f64628
  mtx = (__m_ = 0x00003fa4a3c00508)
}
(lldb) n
Process 3675 stopped
* thread #1, name = 'newsboat', stop reason = signal SIGILL: privileged opcode
    frame #0: 0x0000000829dc762f libc++.so.1`std::__1::recursive_mutex::~recursive_mutex() + 15
libc++.so.1`std::__1::recursive_mutex::~recursive_mutex:
->  0x829dc762f <+15>: ud2    
    0x829dc7631 <+17>: movq   %rax, %rdi
    0x829dc7634 <+20>: callq  0x829d76060    ; ___lldb_unnamed_symbol2709
    0x829dc7639:       int3   
(lldb)

Hm... and now what?
 
Last edited by a moderator:
a little bit deeper

Code: 
* thread #1, name = 'newsboat', stop reason = instruction step over
    frame #0: 0x00000000002bc77e newsboat`newsboat::Cache::~Cache(this=<unavailable>) at cache.cpp:287:1
   284   Cache::~Cache()
   285   {
   286           sqlite3_close(db);
-> 287   }
   288   
   289   void Cache::set_pragmas()
   290   {
(lldb) disassemble
newsboat`newsboat::Cache::~Cache:
    0x2bc760 <+0>:  pushq  %rbp
    0x2bc761 <+1>:  movq   %rsp, %rbp
    0x2bc764 <+4>:  pushq  %rbx
    0x2bc765 <+5>:  pushq  %rax
    0x2bc766 <+6>:  movq   %rdi, %rbx
    0x2bc769 <+9>:  movq   (%rdi), %rdi
    0x2bc76c <+12>: callq  0x4f9b90       ; symbol stub for: sqlite3_close
    0x2bc771 <+17>: addq   $0x10, %rbx
    0x2bc775 <+21>: movq   %rbx, %rdi
    0x2bc778 <+24>: addq   $0x8, %rsp
    0x2bc77c <+28>: popq   %rbx
    0x2bc77d <+29>: popq   %rbp
->  0x2bc77e <+30>: jmp    0x4f9af0       ; symbol stub for: std::__1::recursive_mutex::~recursive_mutex()
    0x2bc783 <+35>: movq   %rax, %rdi
    0x2bc786 <+38>: callq  0x2baa40       ; __clang_call_terminate
(lldb) ni
Process 3806 stopped
* thread #1, name = 'newsboat', stop reason = signal SIGILL: privileged opcode
    frame #0: 0x000000082a77362f libc++.so.1`std::__1::recursive_mutex::~recursive_mutex() + 15
libc++.so.1`std::__1::recursive_mutex::~recursive_mutex:
->  0x82a77362f <+15>: ud2    
    0x82a773631 <+17>: movq   %rax, %rdi
    0x82a773634 <+20>: callq  0x82a722060    ; ___lldb_unnamed_symbol2709
    0x82a773639:       int3   
(lldb)

It fails on the jmp instuction execution. Where to go from there?
 
Last edited by a moderator:
Well, I think there is a bug in how they work with mutexes.

cache.cpp

Code: 
std::vector<std::string> Cache::cleanup_cache(std::vector<std::shared_ptr<RssFeed>> feeds,
    bool always_clean)
{
    // we don't use the std::lock_guard<> here... see comments below
    mtx.lock();
...
Code: 
    // WARNING: THE MISSING UNLOCK OPERATION IS MISSING FOR A
    // PURPOSE! It's missing so that no database operation can occur
    // after the cache cleanup! mtx->unlock();
    return unreachable_feeds;
}

I tried calling mtx.unlock() here, and that fixed the coredump problem.

mtx is declared in cache.h

Code: 
private:
std::recursive_mutex mtx;

Looks like using mtx.lock() is somehow unproper way of working with the mutex in this case.

I think all this better be filed as a bug somewhere. Sorry for flooding here :)
 
At first, I thought I didn't refresh the page before commenting and made a fool of myself answering a question that had already been answered, but it was just a necessary evil of pre-moderation :)
 
Yeh... does that pre-moderation thing always happen or does it stop at some point (maybe after some number of posted messages or at some value of the karma)?
 
igork said:
Yeh... does that pre-moderation thing always happen or does it stop at some point (maybe after some number of posted messages or at some value of the karma)?
Click to expand...
Of course, and in fact, you've already gotten past that point - the first 10 messages :)
 
ah! glad i found this thread, same behaviour (14.3-stable, newsboat via pkg).
good to know it's in the tubes.
cheers,
a-
 
The "privileged opcode" case of SIGILL is pretty much certainly a case of violating an assert in the C++ libraries.
 
You must log in or register to reply here.
Back
Top