kicad-developers team mailing list archive

[Thomas Pointhuber <thomas.pointhuber@xxxxxx>]

Hi,

I rewrote it to use wxDebugReport and wxHandleFatalExceptions. What I
noticed (at least for my build setup), the stack-trace is unusable in
this version for me because it lacks all kicad internals:

```
  <stack>
    <frame level="0"/>
    <frame level="1"/>
    <frame level="2" function="__poll" offset="00000051"/>
    <frame level="3"/>
    <frame level="4" function="g_main_loop_run" offset="000000d2"/>
    <frame level="5" function="gtk_main" offset="000000c3"/>
    <frame level="6" function="wxGUIEventLoop::DoRun()" offset="00000025"/>
    <frame level="7" function="wxEventLoopBase::Run()" offset="00000093"/>
    <frame level="8" function="wxAppConsoleBase::MainLoop()"
offset="00000056"/>
    <frame level="9"/>
    <frame level="10" function="wxEntry(int&amp;, wchar_t**)"
offset="00000045"/>
    <frame level="11"/>
    <frame level="12" function="__libc_start_main" offset="000000f3"/>
    <frame level="13" function="_start" offset="0000002e"/>
  </stack>
```

compared to the stack-trace of glibc, which allows actual debugging
using addr2line:

```
/usr/lib/libc.so.6(+0x37e00)[0x7fa71d60be00]
/usr/lib/libc.so.6(__poll+0x51)[0x7fa71d6c4bb1]
/usr/lib/libglib-2.0.so.0(+0x6cee0)[0x7fa71c82aee0]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0xd2)[0x7fa71c82bf62]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xc3)[0x7fa71d0c2df3]
/usr/lib/libwx_gtk2u_core-3.1.so.1(_ZN14wxGUIEventLoop5DoRunEv+0x25)[0x7fa71fc9b155]
/usr/lib/libwx_baseu-3.1.so.1(_ZN15wxEventLoopBase3RunEv+0x93)[0x7fa71f3f55c3]
/usr/lib/libwx_baseu-3.1.so.1(_ZN16wxAppConsoleBase8MainLoopEv+0x56)[0x7fa71f3b7f36]
pcbnew/pcbnew(+0x37035)[0x55cc4c3d6035]
/usr/lib/libwx_baseu-3.1.so.1(_Z7wxEntryRiPPw+0x45)[0x7fa71f4480d5]
pcbnew/pcbnew(+0x32130)[0x55cc4c3d1130]
/usr/lib/libc.so.6(__libc_start_main+0xf3)[0x7fa71d5f8223]
pcbnew/pcbnew(_start+0x2e)[0x55cc4c3d0f9e]
```

The easiest fix would be to simply copy this stack-trace into the
debug-report as well, if glibc is available.

@Simon,

while it is true that we cannot rely on defined behaviour, most of the
time the stuff is still working. In my implementation, I tried to keep
the amount of called functions low and use stateless functions if
possible. This should prevent most possible errors while executing it.

Nevertheless, I think trying to get some debug info is still better than
simply crash. Using wxDebugReport would mean we have to execute way more
code to get an report, but with the advantage to get more information
into it as well (and platform independent).

Regards, Thomas

Am 19.09.18 um 19:48 schrieb Simon Richter:
> Hi,
> 
> On 19.09.2018 18:38, Thomas Pointhuber wrote:
> 
>> For now, it uses the glibc backtrace function to print a basic
>> stack-trace onto the console, and if possible a crash dump file in the
>> current working directory.
> 
> Then it needs to at least be made glibc specific.
> 
> I'm not fond of these debugging aides inside programs, because IMO
> programs should do one thing and one thing only. Crashed programs are
> crashed, and should not try to do anything that may depend on the
> program state. That most likely includes formatted output.
> 
> Ubuntu, Windows and MacOS have dedicated crash reporting tools that work
> from outside the crashed process and know how to capture all threads and
> full memory contents.
> 
> For that to work we'd need to archive debug information and match it
> against crash reports.
> 
>    Simon
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>

Attachment: signature.asc
Description: OpenPGP digital signature