Default initialize all pointers in Astroid class to avoid segfault in dtor

[ibuclaw]

Under certain circumstances - both deterministic and non-deterministic - astroid can segfault on exit.

For example, when there's another window already running:

$ astroid & bg
[2024-06-05 16:18:20.526090] [0x0000706fccadcec0] [info]    welcome to astroid! - v0.16-20-g41808e88
...
[16:18:20] [0x0000706fccadcec0] [M] [debug] log: stdout: yes

$ astroid 
[2024-06-05 16:20:26.487138] [0x00007f11b1bbaec0] [info]    welcome to astroid! - v0.16-20-g41808e88
Segmentation fault (core dumped)

In all cases the cause is at least one of these pointers pointing at garbage due to being uninitialised.

[ibuclaw]

Added fix for the uncaught exception reported in issue 727.

It turns out that libnotmuch 5.4 has a new API for reading configuration values so there's no need for Astroid to roll its own anymore - alas Debian bullseye has libnotmuch 5.3, otherwise I would have rewritten all this code.

[gauteh]

Hi,

I would recommend not to accommodate old debians. Don't have time to support so many different versions.

tor. 6. juni 2024, 15:55 skrev Iain Buclaw @.***>:

Added fix for the uncaught exception reported in issue 727.

It turns out that libnotmuch 5.4 has a new API for reading configuration values so there's no need for Astroid to roll its own anymore - alas Debian bullseye has libnotmuch 5.3, otherwise I would have rewritten all this code.

— Reply to this email directly, view it on GitHub https://github.com/astroidmail/astroid/pull/753#issuecomment-2152605916, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAN365XZ2BUD2ZH6SCVGHDZGBS5HAVCNFSM6AAAAABI23V2GOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJSGYYDKOJRGY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[ibuclaw]

Hi, I would recommend not to accommodate old debians. Don't have time to support so many different versions.

Sure, have nothing to disagree about that, my thinking is that fixing the issue and setting a new minimum version requirement for libnotmuch (5.4 - or notmuch 0.32) are two separate things.

There is a new function in libnotmuch 5.4 - however migrating to using it would mean a rewrite away from using ptree to using libnotmuch API directly for reading the notmuch ini file (i.e: to read a boolean value)

Adding in a new catch handler in the meantime is a trivial fix.

[jorsn]

my thinking is that fixing the issue and setting a new minimum version requirement for libnotmuch (5.4 - or notmuch 0.32) are two separate things. -- @ibuclaw

I agree, since my first priority is to release a version that works. Then, one can still modernize and clean up.

@gauteh Any objections against merging this ?

[gauteh]

Sounds good. Note that there has been a bunch of issues in lieer regarding the new config system, where some values are in the db, some in the config file. Doesn't appear to work perfectly always. But probably not something astroid should worry about.