Re: slowly decommission bugzilla?

On Sat, 28 Feb 2026 19:29:24 +0100 (CET)
Richard Weinberger <[email protected]> wrote:

> > Apparently not enough people know about this.

decode_stacktrace is awesome. It's better than my old method of using
gdb with li *<addr>, as it also handles inlined functions and gives you
the file and line number of what called the inlined function.

> > 
> >  uart_write (drivers/tty/serial/serial_core.c:72
> > drivers/tty/serial/serial_core.c:598)
> >  handle_tx (drivers/net/caif/caif_serial.c:237)
> >  caif_xmit (drivers/net/caif/caif_serial.c:284)
> >  dev_hard_start_xmit (./include/linux/netdevice.h:4833
> > ./include/linux/netdevice.h:4847 net/core/dev.c:3601
> > net/core/dev.c:3617)
> > 
> > which is really a lot easier for people to figure out where things happened.  
> 
> Of course. But I had a different use case in mind.
> I thought about pasting whatever stack trace a user finds in dmesg/syslog
> into a web interface to find the most suitable mailing list to report to.
> 
> *If* debuginfo and tooling is available to the user, of course they should
> include the decoded stack trace to the report.
> How to do that should be included in the instructions on how to report
> the issue by mail.

What would be great is if a tool took the current crash, ran it through
decode_stacktrace.pl, and then run the files it produces through
get_maintainers.pl and then Cc a subset of people that are most likely
to be able to figure it out.

-- Steve