drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Stephen Brennan]

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

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Stephen Brennan]

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.

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

Thanks,
Stephen

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Christian Heusel]

[-- Attachment #1: Type: text/plain, Size: 2318 bytes --]

On 25/01/02 12:31AM, Stephen Brennan wrote:
> Stephen Brennan <stephen@brennan.io> writes:
> > Hi Christian,

Hey Stephen,

> >
> > 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.

I was not yet aware of this!

> >
> > 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.
> 
> 2. I'd say the best way forward would be a simple rebuild of drgn
> against libkdumpfile 0.5.5.
> 
> Thanks,
> Stephen

thanks for your report and suggestions to fix the underlying issue! It
turns out I somehow missed the soname bump in libkdumpfile's last
release (also I'm a bit annoyed that it had one in a patch release)
... 😅

Sorry for any trouble this has caused you, this should be fixed with
drgn 0.0.30-3! Additionally to the rebuild I included the patch you
suggested at first, as it applied easily and fixes the lifetime issue!

Cheers,
Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Petr Tesařík]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

On Thu, 2 Jan 2025 09:57:52 +0100
Christian Heusel <gromit@archlinux.org> wrote:

> On 25/01/02 12:31AM, Stephen Brennan wrote:
> > Stephen Brennan <stephen@brennan.io> writes:  
> > > Hi Christian,  
> 
> Hey Stephen,
> 
> > >
> > > 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.  
> 
> I was not yet aware of this!
> 
> > >
> > > 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.
> > 
> > 2. I'd say the best way forward would be a simple rebuild of drgn
> > against libkdumpfile 0.5.5.
> > 
> > Thanks,
> > Stephen  
> 
> thanks for your report and suggestions to fix the underlying issue! It
> turns out I somehow missed the soname bump in libkdumpfile's last
> release (also I'm a bit annoyed that it had one in a patch release)
> ... 😅

Hey, you may want to know that libkdumpfile (package) does not follow
any kind of semantic versioning rules. So, there's nothing like a
"patch release".

I will reconsider this approach with the release of v1.0, but that's
not planned until there is feature parity with the crash utility...

However, since some people have already found the library useful, I
maintain libtool versioning, which takes care of API and ABI updates
(and makes it possible to install multiple ABI-incompatible versions on
a single system).

Petr T

[-- Attachment #2: Digitální podpis OpenPGP --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Christian Heusel]

[-- Attachment #1: Type: text/plain, Size: 1119 bytes --]

On 25/01/02 02:57PM, Petr Tesařík wrote:
> On Thu, 2 Jan 2025 09:57:52 +0100
> Christian Heusel <gromit@archlinux.org> wrote:
> > thanks for your report and suggestions to fix the underlying issue! It
> > turns out I somehow missed the soname bump in libkdumpfile's last
> > release (also I'm a bit annoyed that it had one in a patch release)
> > ... 😅
> 
> Hey, you may want to know that libkdumpfile (package) does not follow
> any kind of semantic versioning rules. So, there's nothing like a
> "patch release".

Alright, thats good to know!

> I will reconsider this approach with the release of v1.0, but that's
> not planned until there is feature parity with the crash utility...
> 
> However, since some people have already found the library useful, I
> maintain libtool versioning, which takes care of API and ABI updates
> (and makes it possible to install multiple ABI-incompatible versions on
> a single system).

Yeah again as I wrote initially, missing the soname bump one is
definitely on me!

> Petr T

Hope y'all had a great start into the year 🎉🎆

    ~ Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Stephen Brennan]

Christian Heusel <gromit@archlinux.org> writes:
> On 25/01/02 12:31AM, Stephen Brennan wrote:
>> Stephen Brennan <stephen@brennan.io> writes:
>> > Hi Christian,
>
> Hey Stephen,
>
>> >
>> > 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.
>
> I was not yet aware of this!
>
>> >
>> > 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.
>> 
>> 2. I'd say the best way forward would be a simple rebuild of drgn
>> against libkdumpfile 0.5.5.
>> 
>> Thanks,
>> Stephen
>
> thanks for your report and suggestions to fix the underlying issue! It
> turns out I somehow missed the soname bump in libkdumpfile's last
> release (also I'm a bit annoyed that it had one in a patch release)
> ... 😅
>
> Sorry for any trouble this has caused you, this should be fixed with
> drgn 0.0.30-3! Additionally to the rebuild I included the patch you
> suggested at first, as it applied easily and fixes the lifetime issue!

No trouble at all, and thanks for the quick turnaround. I've got the
update and verified it is working.

Happy new year!

Thanks,
Stephen

> Cheers,
> Chris

Re: drgn 0.0.30 and libkdumpfile 0.5.5 incompatibility in Arch

[Petr Tesařík]

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