public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename
@ 2023-06-09 15:42 fabian_kessler at gmx dot de
  2023-06-09 15:56 ` [Bug libstdc++/110196] " pinskia at gcc dot gnu.org
                   ` (11 more replies)
  0 siblings, 12 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 15:42 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

            Bug ID: 110196
           Summary: stacktrace_entry does not print origin binary filename
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fabian_kessler at gmx dot de
  Target Milestone: ---

Using the current release stacktrace header results in a weird looking
stacktrace, because the origin filename is not included:

```
0# crashHandler at
/mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/CrashHandler.cpp:76
   1#      at :0
   2# pthread_kill at :0
   3# raise at :0
   4# MainWindow::MainWindow(GladeSearchpath*, Control*, _GtkApplication*) at
/mnt/c/Users/Febbe/workspace/xournalpp/src/core/gui/MainWindow.cpp:54
   5# std::_MakeUniq<MainWindow>::__single_object std::make_unique<MainWindow,
GladeSearchpath*, Control*, _GtkApplication*>(GladeSearchpath*&&, Control*&&,
_GtkApplication*&&) at :0
   6# on_startup at
/mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/XournalMain.cpp:485
   7# g_closure_invoke at :0
   8#      at :0
   9# g_signal_emit_valist at :0
  10# g_signal_emit at :0
  11# g_application_register at :0
  12#      at :0
  13# g_application_run at :0
  14# XournalMain::run(int, char**) at
/mnt/c/Users/Febbe/workspace/xournalpp/src/core/control/XournalMain.cpp:690
```

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print origin binary filename
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
@ 2023-06-09 15:56 ` pinskia at gcc dot gnu.org
  2023-06-09 15:58 ` fabian_kessler at gmx dot de
                   ` (10 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-09 15:56 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am trying to understand the issue here?
Is what you are asking is that the " at :0" should not be printed out? Or the
issue is the source line cannot be found.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print origin binary filename
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
  2023-06-09 15:56 ` [Bug libstdc++/110196] " pinskia at gcc dot gnu.org
@ 2023-06-09 15:58 ` fabian_kessler at gmx dot de
  2023-06-09 16:07 ` fabian_kessler at gmx dot de
                   ` (9 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 15:58 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #2 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
(In reply to Andrew Pinski from comment #1)
> I am trying to understand the issue here?
> Is what you are asking is that the " at :0" should not be printed out? Or
> the issue is the source line cannot be found.

The issue is, that the origin library, in this case libc.so/gtk.so/glib.so is
not shown. In all other lines, xournalpp as executable is missing.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print origin binary filename
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
  2023-06-09 15:56 ` [Bug libstdc++/110196] " pinskia at gcc dot gnu.org
  2023-06-09 15:58 ` fabian_kessler at gmx dot de
@ 2023-06-09 16:07 ` fabian_kessler at gmx dot de
  2023-06-09 16:09 ` [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from pinskia at gcc dot gnu.org
                   ` (8 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 16:07 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #3 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
It may be, because backtrace_create_state is called without a filename.
Also, backtrace_create_state is ment to be called just once per execution,
because it allocates unfreeable memory. Maybe, a singleton would be the way to
go here.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (2 preceding siblings ...)
  2023-06-09 16:07 ` fabian_kessler at gmx dot de
@ 2023-06-09 16:09 ` pinskia at gcc dot gnu.org
  2023-06-09 16:16 ` fabian_kessler at gmx dot de
                   ` (7 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-06-09 16:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
            Summary|stacktrace_entry does not   |stacktrace_entry does not
                   |print origin binary         |print which library the
                   |filename                    |function was from

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (3 preceding siblings ...)
  2023-06-09 16:09 ` [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from pinskia at gcc dot gnu.org
@ 2023-06-09 16:16 ` fabian_kessler at gmx dot de
  2023-06-09 16:17 ` fabian_kessler at gmx dot de
                   ` (6 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 16:16 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #4 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
Indeed, changing _S_init to the following did the trick:

```
  static backtrace_state *_S_init() {

    static backtrace_state *__state = []() {
      auto getpath = []() -> std::string {
        char buf[PATH_MAX + 1];
        if (readlink("/proc/self/exe", buf, sizeof(buf) - 1) == -1) {
          return "";
        }
        std::string str(buf);
        return str.substr(0, str.rfind('/'));
      };

      auto exec_filename = getpath();
      return backtrace_create_state(exec_filename.c_str(), 1, _S_err_handler,
                                    nullptr);
    }();
    return __state;
  }
```

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (4 preceding siblings ...)
  2023-06-09 16:16 ` fabian_kessler at gmx dot de
@ 2023-06-09 16:17 ` fabian_kessler at gmx dot de
  2023-06-09 16:18 ` fabian_kessler at gmx dot de
                   ` (5 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 16:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #5 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
Indeed, changing _S_init to the following improved it:

```
  static backtrace_state *_S_init() {

    static backtrace_state *__state = []() {
      auto getpath = []() -> std::string {
        char buf[PATH_MAX + 1];
        if (readlink("/proc/self/exe", buf, sizeof(buf) - 1) == -1) {
          return "";
        }
        std::string str(buf);
        return str.substr(0, str.rfind('/'));
      };

      auto exec_filename = getpath();
      return backtrace_create_state(exec_filename.c_str(), 1, _S_err_handler,
                                    nullptr);
    }();
    return __state;
  }
```

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (5 preceding siblings ...)
  2023-06-09 16:17 ` fabian_kessler at gmx dot de
@ 2023-06-09 16:18 ` fabian_kessler at gmx dot de
  2023-06-09 16:47 ` fabian_kessler at gmx dot de
                   ` (4 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 16:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #6 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
output is now 
```
   0# main at /mnt/c/Users/Febbe/workspace/test/test/main.cpp:7
   1# __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58
   2# __libc_start_main_impl at ../csu/libc-start.c:392
   3# _start at :0
   4# 
```

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (6 preceding siblings ...)
  2023-06-09 16:18 ` fabian_kessler at gmx dot de
@ 2023-06-09 16:47 ` fabian_kessler at gmx dot de
  2023-06-09 20:56 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-09 16:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #7 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
To fix this some sort of 
char ** __backtrace_symbols (void *const *array, int size)
must be used internally.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (7 preceding siblings ...)
  2023-06-09 16:47 ` fabian_kessler at gmx dot de
@ 2023-06-09 20:56 ` redi at gcc dot gnu.org
  2023-06-09 21:38 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-09 20:56 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Last reconfirmed|                            |2023-06-09

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to fabian_kessler@gmx.de from comment #3)
> Also, backtrace_create_state is ment to be called just once per execution,
> because it allocates unfreeable memory. Maybe, a singleton would be the way
> to go here.

It is only called once, isn't it?


(In reply to fabian_kessler@gmx.de from comment #5)
> Indeed, changing _S_init to the following improved it:
> 
> ```
>   static backtrace_state *_S_init() {
> 
>     static backtrace_state *__state = []() {
>       auto getpath = []() -> std::string {
>         char buf[PATH_MAX + 1];
>         if (readlink("/proc/self/exe", buf, sizeof(buf) - 1) == -1) {

This isn't portable, not all systems have /proc/self/exe, or readlink.

I think it would be better to move this function into the library, and use
std::filesystem::read_symlink.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (8 preceding siblings ...)
  2023-06-09 20:56 ` redi at gcc dot gnu.org
@ 2023-06-09 21:38 ` redi at gcc dot gnu.org
  2023-06-10 10:21 ` fabian_kessler at gmx dot de
  2023-06-10 12:57 ` fabian_kessler at gmx dot de
  11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2023-06-09 21:38 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
libbacktrace is supposed to have code to do this, see fileline_initialize in
libbacktrace/fileline.c

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (9 preceding siblings ...)
  2023-06-09 21:38 ` redi at gcc dot gnu.org
@ 2023-06-10 10:21 ` fabian_kessler at gmx dot de
  2023-06-10 12:57 ` fabian_kessler at gmx dot de
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-10 10:21 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #10 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
> It is only called once, isn't it?

Actually, _S_init is even called in a loop. And the singleton pattern is also a
code extension from me. Therefore, backtrace_create_state is also called in a
loop.

> 
> This isn't portable, not all systems have /proc/self/exe, or readlink.
> 
> I think it would be better to move this function into the library, and use
> std::filesystem::read_symlink.

Yes, that code snipped was just to test my assumption, which was only partially
correct. Adding the path improved the stacktrace, but did not add the
originating library.
I don't feel experienced, to contribute STL code for more than x86_64.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from
  2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
                   ` (10 preceding siblings ...)
  2023-06-10 10:21 ` fabian_kessler at gmx dot de
@ 2023-06-10 12:57 ` fabian_kessler at gmx dot de
  11 siblings, 0 replies; 13+ messages in thread
From: fabian_kessler at gmx dot de @ 2023-06-10 12:57 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110196

--- Comment #11 from fabian_kessler at gmx dot de <fabian_kessler at gmx dot de> ---
With the following code extension, I get what I want, but this may also be
platform dependent:

class stacktrace_entry{
// ...  
  std::string _symbol(uintptr_t const pc) const {
    Dl_info info;
    int status;
    link_map *map;
    status = dladdr1((void const *)(pc), &info, reinterpret_cast<void
**>(&map),
                     RTLD_DL_LINKMAP);
    return std::string(info.dli_fname ?: "");
  }
// ...
}

// ...

inline std::ostream &operator<<(std::ostream &__os,
                                const stacktrace_entry &__f) {
  std::string __desc, __file;
  int __line;
  if (__f._M_get_info(&__desc, &__file, &__line)) {
    __os.width(4);
    __os << __f._symbol(__f._M_pc) << "(" << __desc << ") at " << __file << ':'
         << __line;
  }
  return __os;
}

Outputs:

   0# /mnt/c/Users/Febbe/workspace/test/build/test_stacktrace_20(main) at
/mnt/c/Users/Febbe/workspace/test/test/main.cpp:7
   1# /lib/x86_64-linux-gnu/libc.so.6(__libc_start_call_main) at
../sysdeps/nptl/libc_start_call_main.h:58
   2# /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main_impl) at
../csu/libc-start.c:360
   3# /mnt/c/Users/Febbe/workspace/test/build/test_stacktrace_20(_start) at :0

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2023-06-10 12:57 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-06-09 15:42 [Bug libstdc++/110196] New: stacktrace_entry does not print origin binary filename fabian_kessler at gmx dot de
2023-06-09 15:56 ` [Bug libstdc++/110196] " pinskia at gcc dot gnu.org
2023-06-09 15:58 ` fabian_kessler at gmx dot de
2023-06-09 16:07 ` fabian_kessler at gmx dot de
2023-06-09 16:09 ` [Bug libstdc++/110196] stacktrace_entry does not print which library the function was from pinskia at gcc dot gnu.org
2023-06-09 16:16 ` fabian_kessler at gmx dot de
2023-06-09 16:17 ` fabian_kessler at gmx dot de
2023-06-09 16:18 ` fabian_kessler at gmx dot de
2023-06-09 16:47 ` fabian_kessler at gmx dot de
2023-06-09 20:56 ` redi at gcc dot gnu.org
2023-06-09 21:38 ` redi at gcc dot gnu.org
2023-06-10 10:21 ` fabian_kessler at gmx dot de
2023-06-10 12:57 ` fabian_kessler at gmx dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).