Advice on a memory issue
by William Brown
https://pagure.io/389-ds-base/pull-request/50379
This code is not yet ready to be merged. I'm currently having a problem with freeing the attrsyntaxinfo struct as part of the test.
If the code is as is I get:
=================================================================
==98363==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
#1 0x7fbc40a34be6 in slapi_ch_calloc /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
#2 0x40499c in attr_syntax_add_from_name /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
#3 0x404b22 in test_libslapd_schema_filter_validate_simple /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:56
#4 0x7fbc40d340d8 (/usr/lib64/libcmocka.so.0+0x50d8)
Objects leaked above:
0x60e000000d60 (160 bytes)
Direct leak of 160 byte(s) in 1 object(s) allocated from:
#0 0x7fbc40e28538 in calloc (/usr/lib64/libasan.so.5+0xec538)
#1 0x7fbc40a34be6 in slapi_ch_calloc /home/william/development/389ds/ds/ldap/servers/slapd/ch_malloc.c:175
#2 0x40499c in attr_syntax_add_from_name /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:25
#3 0x404b0f in test_libslapd_schema_filter_validate_simple /home/william/development/389ds/ds/test/libslapd/schema/filter_validate.c:55
#4 0x7fbc40d340d8 (/usr/lib64/libcmocka.so.0+0x50d8)
Objects leaked above:
0x60e000000ba0 (160 bytes)
SUMMARY: AddressSanitizer: 320 byte(s) leaked in 2 allocation(s).
However, if I free *a and *b, with attr_syntax_free, or slapi_ch_free, I get a double free error. The size of 160 bytes correlates to the sizeof(struct attrsyntaxinfo) but looking in gdb during attr_syntax_delete, the attr_syntax_free is called on asi as provided.
So I'm not 100% sure what's going wrong here, but I'm not thoroughly experienced in this part of the code, so feedback would be really helpful about this resource issue.
Thanks!
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years, 11 months
Use of rust for new logging backend
by William Brown
Hi all,
So it's been a while since I pushed this, but again, I think I want to bring this up. I'd like to write the new logging backend in Rust.
I'll start with a summary:
Pros:
* Faster development time due to stricter code correctness guarantees
* Modern and safe language to lower number of bugs in implementation
* Much better libraries for interacting with things like json and thread safety
Cons:
* Another language in the codebase ...
* We need to learn it to work on it
* Vendors need to be ready to build with the toolchain
I've talked through some of these thoughts with Mark a bit, and I really think it's time we did this - or gave up on pursuing it. I have been running the rust enabled version of ds for a few years now with no issues. SUSE is also in a position where they are able to and ready to build DS with Rust (I'm assuming RH could easily also be brought to parity here).
So the main barrier becomes us: the most common argument is we don't know enough or have enough experience. However I think this argument is flawed, in the fact that there are many parts of the code where we already only have 1 or 2 experts in that area - often when we look into a bug or a feature, we always have to learn new things, we have to read the code, understand even the unique styles of how that was written for the time, and then do work. This would be no different. I think we are all capable of learning and working with these tools.
By this point, Gnome is looking into Rust as a mainline part of the desktop, Samba has started to look into it, Firefox is already shipping Rust components. I think that Rust is here to stay, and is not some passing trend.
So what do we think? I think if there are no major objections I would like to do this in Rust. I'll also commit to providing C-Rust FFI documentation for the team, resources to help understand what's going on, and like always, I will be sure to comment all my code thoroughly as part of this improvement.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
4 years, 11 months
