Debug package repository to avoid GDB: "this=<optimized out>"

[Al2Klimov]

I've spotted a crash and v2.11 even helped me reproducing it by letting it occur more often (destiny's irony).

However even with the snapshots I hit the breakpoint, but get this:

Icinga/icinga2#6  0x00005583a99fd710 in icinga::Checkable::IsReachable (this=<optimized out>, dt=<optimized out>, failedDependency=<optimized out>, rstack=<optimized out>)

Please could you build the snapshots with -O0, -Og, -g or similar so nothing gets optimized out?

[bunghi]

Since upgraded to 2.11 I also had crashes with references to GDB, report output:

$ cat report.1569312889.121968
Caught unhandled exception.
Current time: 2019-09-24 10:14:49 +0200

  Application version: r2.11.0-1

System information:
  Platform: Debian GNU/Linux
  Platform version: 9 (stretch)
  Kernel: Linux
  Kernel version: 4.9.0-11-amd64
  Architecture: x86_64

Build information:
  Compiler: GNU 6.3.0
  Build host: runner-LTrJQZ9N-project-298-concurrent-0

Application information:

General paths:
  Config directory: /etc/icinga2
  Data directory: /var/lib/icinga2
  Log directory: /var/log/icinga2
  Cache directory: /var/cache/icinga2
  Spool directory: /var/spool/icinga2
  Run directory: /run/icinga2

Old paths (deprecated):
  Installation root: /usr
  Sysconf directory: /etc
  Run directory (base): /run
  Local state directory: /var

Internal paths:
  Package data directory: /usr/share/icinga2
  State path: /var/lib/icinga2/icinga2.state
  Modified attributes path: /var/lib/icinga2/modified-attributes.conf
  Objects path: /var/cache/icinga2/icinga2.debug
  Vars path: /var/cache/icinga2/icinga2.vars
  PID path: /run/icinga2/icinga2.pid

Error: [json.exception.parse_error.101] parse error at line 1, column 28: syntax error while parsing value - unexpected '{'; expected end of input


        (0) icinga2: icinga::JsonDecode(icinga::String const&) (+0x779) [0x55e373ddfac9]
        (1) icinga2: icinga::Process::DoEvents() (+0x295) [0x55e373e33bf5]
        (2) icinga2: icinga::Process::IOThreadProc(int) (+0x3cd) [0x55e373e3529d]
        (3) libstdc++.so.6: <unknown function> (+0xb9e6f) [0x7fa157ae2e6f]
        (4) libpthread.so.0: <unknown function> (+0x74a4) [0x7fa1589194a4]
        (5) libc.so.6: clone (+0x3f) [0x7fa157257d0f]



***
* This would indicate a runtime problem or configuration error. If you believe this is a bug in Icinga 2
* please submit a bug report at https://github.com/Icinga/icinga2 and include this stack trace as well as any other
* information that might be useful in order to reproduce this problem.
***
Failed to launch GDB: No such file or directory

[Al2Klimov]

Hello @bunghi and thank you for reporting!

Please could you open a separate issue? This one is not about a particular crash, but about debugging crashes in general.

Best,
AK

[bunghi]

Hello @bunghi and thank you for reporting!

Please could you open a separate issue? This one is not about a particular crash, but about debugging crashes in general.

Best,
AK

Already here: Icinga/icinga2#7532

[dnsmichi]

@bunghi As mentioned the linked issue, yours is different. New issue please.

@Al2Klimov As noted over at GitLab, I don't think that's a good idea. For immediate development tests, you may use branches and artifacts, for the long run, we should discuss with @lippserd whether we want a dedicated repository with debug packages. They run slower (in some regions 10 times slower with an increased memory overhead) and do not qualify for test environments or customer tests.

[Al2Klimov]

Sure, I could misuse our GitLab for making packages for my private setup, but others can't.

[Al2Klimov]

... so +1 for (possibly extra) debug packages.

[Al2Klimov]

Or even better: public Docker images to be run with a local Icinga 2 Git repo mounted in which automatically build packages.

[dnsmichi]

Discussed that offline, needs to be taken into account for future CI topics @lippserd @bobapple

[julianbrost]

I don't really see the use case for these packages. If we are debugging something ourselves or some user is with our help, we can also build these packages on demand. I mean what are the odds that some user is really debugging on their own on a level where they are fiddling around in GDB and miss debug information, but are not able to build icinga2 themselves? So in my opinion, it would be enough to have something like "for debug packages, uncomment the following lines" somewhere in our source packages.