Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

["Petr Tesařík" <petr@tesarici.cz>]

On Thu, 02 Jan 2025 00:31:59 -0800
Stephen Brennan <stephen@brennan.io> wrote:

> Stephen Brennan <stephen@brennan.io> writes:
> > Hi Christian,
> >
> > I think you may already be aware of this, but I wanted to let you know
> > that there's an incompatibility with drgn 0.0.30-2 and libkdumpfile
> > 0.5.5-1 on Arch. libkdumpfile 0.5.5 changed some APIs in a
> > backward-incompatible way. Building drgn against the new version fails,
> > and running a version built against 0.5.4 of course fails due to the
> > soname change. The current drgn 0.0.30-2 on Arch's repositories was
> > built against 0.5.4.
> >
> > Thus a user installing drgn & libkdumpfile on Arch, who is fully
> > up-to-date, gets this:
> >
> > ImportError: libkdumpfile.so.10: cannot open shared object file: No such file or directory
> >
> > The incompatibility is fixed in drgn's main branch by the changes in
> > [1]. Unfortunately, that was merged after drgn 0.0.30 was released.
> > Some major changes have been merged since then, so I don't think a
> > 0.0.31 release is likely for a few months. So I think it may be a good
> > idea to carry the two commits in [1] as downstream patches in a new
> > 0.0.30-3 release. I'd be happy to implement those changes if it'd help.
> >
> > I'm Ccing the linux-debuggers mailing list for posterity, as well as
> > Omar and Petr as an FYI.
> >
> > Thanks,
> > Stephen
> >
> > [1]: https://github.com/osandov/drgn/pull/452  
> 
> 
> Sorry, I was a bit mistaken here:
> 
> 1. drgn 0.0.30 DOES build successfully with libkdumpfile 0.5.5. I
> misread the changes there. As far as I can tell, there may be a small
> memory leak when using 0.0.30 with 0.5.5, but nothing major.

Yes, the PRSTATUS blob data will leak. To be clear, the memory leak
is not even relevant unless your program releases many drgn objects.
Most use cases involve a single instance which is released at program
exit, and then there's no practical difference.

> 2. I'd say the best way forward would be a simple rebuild of drgn
> against libkdumpfile 0.5.5.

Agreed.

Petr T