Ruby 3.2.x and warning: undefining the allocator of T_DATA class swig_runtime_data


Product Version:

Please give a brief summary of your issue:
Only with Ruby versions 3.2.x, getting warning about undefining the allocator for swig_runtime_data.

Please describe your issue and provide steps to reproduce it:
When initializing the SDK we see this warning. Example script:

# frozen_string_literal: true

require '/usr/local/PDFNetC/Lib/PDFNetRuby'



/usr/local/PDFNetC/Lib/ warning: undefining the allocator of T_DATA class swig_runtime_data

It looks like this is an issue in Swig which was brought up in this GitHub issue 2257 and possibly fixed. The warning is apparently set up as a way to help Ruby C extension developers meet requirements by telling them to either explicitly define their own allocator for T_DATA objects, or undefined it.

I’ve tested compiling the latest development version from Swig and I do indeed see this warning disappear. The issue with this is that we don’t think it’s a good idea to go this route for our production deployments since it’s not an official “stable” release.

One thing we did notice is that Ruby 3.1.x doesn’t output this warning. But I think Ruby 3.1.x is just silently happy with it according to the description in the GitHub issue mentioned above.

My question is, does the Apryse developers suggest continuing to use Ruby 3.2 and ignoring this warning for now, or do you think we should use Ruby 3.1.x?

Otherwise, what is the newest version of Ruby that is officially suggested/supported? Your documentation states 2.6+, but my team would highly prefer to stick to version 3.x. Ideally 3.2.x, but we can work with 3.1.x if that’s the better supported option. Appreciate any thoughts and suggestions about this.

As an aside, I created a separate topic about our app crashing due to memory allocation errors. I wasn’t certain that these are related, but since this warning is about memory allocation I mention it here in case these issues share the same root cause.

Please provide a link to a minimal sample where the issue is reproducible:
See above.

Thank you for the detailed report, I have passed this onto the team for further investigation.

Officially we still support only 2.x, but I believe there are Apryse users using 3.1.

The Ruby part is just a simple shim/wrapper, so as long as the API calls pass through, there is no further functional difference as everything is actually done in the native binary, so it is perfectly safe for you to generate and use your own Ruby bindings.

I will update you once I know more from the team.

1 Like

Hi James,

Feel free to use whichever version works for you, as this issue seems to not have an impact on the running of the library.

While our website states we only support 2.x, we have actively tested Ruby on 3.x versions and have it working. We may be updating that support line some time in the near future.