Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Issue] ulfius_url_{encode,decode} call malloc instad of o_malloc #206

Closed
laf0rge opened this issue Dec 8, 2021 · 3 comments · Fixed by #207
Closed

[Issue] ulfius_url_{encode,decode} call malloc instad of o_malloc #206

laf0rge opened this issue Dec 8, 2021 · 3 comments · Fixed by #207

Comments

@laf0rge
Copy link
Contributor

laf0rge commented Dec 8, 2021

Describe the issue

All ulfius versions since commit 36c802a (i.e. v2.6.0 ... v2.7.6) are crashing our application software (osmo-remsim-server, see https://osmocom.org/projects/osmo-remsim/wiki and https://git.osmocom.org/osmo-remsim).
In all the Osmocom software we are using the libtalloc memory allocator, as it helps significantly with debugging memory leaks. For years, we are using orcania's support for hooking in custom memory allocators, which is also explicitly documented as a feature in API.md of ulfius.

However, since the above mentioned commit, ulfius started to directly call malloc() in url_decode, ulfius_url_decode and ulfius_uil_encode rather than using the o_malloc wrapper. This means that the memory is allocated using libc malloc, but later on then handed to talloc_free (via o_free) -> boom. You cannot allocate with one allocator and free with the other.

To Reproduce
You could build + start osmo-remsim-server and then issue a HTTP request against the built-in ulfius based REST server. This will result in the backtrace that is seen at https://osmocom.org/issues/5343

Expected behavior
The expected behavior is that all ulfius internal allocations will use o_malloc() and then o_free().

The only way to prevent these kind of bugs or regressions is to use a malloc/free wrapper in the entire ulfius test suite which would immediately detect if ever some pointer is passed to o_free which has not previously been seen at o_malloc.

System (please complete the following information):

  • OS/Environment: Debian 11 + unstable
  • Ulfius Version 2.7.6
  • Source installation: Debian distribution packages
@laf0rge
Copy link
Contributor Author

laf0rge commented Dec 8, 2021

I'm currently testing a related fix

@babelouest
Copy link
Owner

Hello @laf0rge ,

Thanks for noticing, and providing the pull request, I think it's worth a new release!

@laf0rge
Copy link
Contributor Author

laf0rge commented Dec 8, 2021

thanks for the quick reaction. As I mentioned, I think the only way to avoid such regressions is to alsways use some wrapper during development/testing, whch would ASSERT that any memory passed to o_free() has previously been returned by o_malloc() or o_realloc().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants