IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
circular references (circular references are allowed, they just need
to be handled carefully inside talloc)
- mark talloc_reference() pointers nicely in the --leak-report-full
code, so you see what has a reference to what in a useful manner
RPC-SAMR torture test. This closes the samr connection before working
on a open domain handle. The server is supposed to know that the open
domain handle still holds a reference to the connection, so the
connection remains valid even though it has been closed.
void *talloc_reference(const void *context, const void *ptr);
this function makes a secondary reference to ptr, and hangs it off the
given context. This greatly simplifies some of the current reference
counting code in the samr server and I suspect it will be widely used
in other places too.
the way you use it is like this:
domain_state->connect_state = talloc_reference(domain_state, connect_state);
that makes the element connect_state of domain_state a secondary
reference to connect_state. The connect_state structure will then only
be freed when both domain_state and the original connect_state go
away, allowing you to free them independently and in any order.
you could do this alrady using a talloc destructor, and that is what
the samr server did previously, but that meant this construct was
being reinvented in several places. So this convenience function sets
up the destructor for you, giving a much more convenient and less
error prone API.
a const pointer really means that "the data pointed to by this pointer
won't change", and that is certainly true of talloc(). The fact that
some behind-the-scenes meta-data can change doesn't matter from the
point of view of const.
this fixes a number of const warnings caused by const data structures
being passed as talloc contexts. That will no longer generate a
warning.
also changed the talloc leak reporting option from --leak-check to
--leak-report, as all it does is generate a report on exit. A new
--leak-report-full option has been added that shows the complete tree
of memory allocations, which is is quite useful in tracking things down.
NOTE: I find it quite useful to insert talloc_report_full(ptr, stderr)
calls at strategic points in the code while debugging memory
allocation problems, particularly before freeing a major context (such
as the connection context). This allows you to see if that context has
been accumulating too much data, such as per-request data, which
should have been freed when the request finished.
taking a context (so when you pass a NULL pointer you end up with
memory in a top level context). Fixed it by changing the API to take a
context. The context is only used if the pointer you are reallocing is
NULL.
This sort of bug happens quite easily with the new talloc_realloc()
interface. talloc_realloc() now looks like this:
void *talloc_realloc(void *ptr, size_t size);
and if ptr is not NULL then everything is fine. If ptr is NULL then
talloc_realloc() presumes you want to allocate in the NULL context,
which is probably not what is wanted.
For now the solution is to initialise ptr like this:
ptr = talloc(mem_ctx, 0);
so when the realloc happens it has a context to get hold of.
I might change the interface of talloc_realloc() later to prevent this
problem in a more robust manner
rather than manual reference counts
- properly support SMBexit in the cifs and posix backends
- added a logoff method to all backends
With these changes the RAW-CONTEXT test now passes against the posix backend
to get auto-naming of pointers very cheaply.
- fixed a couple of memory leaks found with the new tricks
A typical exit report for smbd is now:
talloc report on 'null_context' (total 811 bytes in 54 blocks)
auth/auth_sam.c:334 contains 20 bytes in 1 blocks
struct auth_serversupplied_info contains 498 bytes in 33 blocks
UNNAMED contains 8 bytes in 1 blocks
lib/data_blob.c:40 contains 16 bytes in 1 blocks
iconv(CP850,UTF8) contains 61 bytes in 4 blocks
iconv(UTF8,CP850) contains 61 bytes in 4 blocks
iconv(UTF8,UTF-16LE) contains 67 bytes in 4 blocks
iconv(UTF-16LE,UTF8) contains 67 bytes in 4 blocks
UNNAMED contains 13 bytes in 1 blocks
which is much better than before
connection termination cleanup, and to ensure that the event
contexts are properly removed for every process model
- gave auth_context the new talloc treatment, which removes another
source of memory leaks.
auto-derived from the type you are allocating. This is done with
basically zero overhead by relying on the stringify operator in cpp
producing string constants.
the result is that --leak-check nicely names all pointers that come
from talloc_p()
and can't properly handle leaks of doubly linked lists which we use a
lot (as the memory is always reachable). Even with --show-reachable
its hard to track leaks down sometimes.
I realised that talloc does have the necessary information to track
these, and by using the cascading property of the new talloc it can
report on leaks in a much more succinct fashion than valgrind can.
I have added a new samba option --leak-check that applies to all Samba
tools. When enabled it prints a leak report summarising all top level
contexts that are present when the program exits. A typical report
looks like this:
talloc report on 'null_context' (total 1071 bytes in 52 blocks)
iconv(CP850,UTF8) contains 43 bytes in 3 blocks
UNNAMED contains 24 bytes in 1 blocks
UNNAMED contains 24 bytes in 1 blocks
dcesrv_init contains 604 bytes in 26 blocks
server_service contains 120 bytes in 6 blocks
UNNAMED contains 24 bytes in 1 blocks
UNNAMED contains 24 bytes in 1 blocks
server_service contains 104 bytes in 4 blocks
server_context contains 12 bytes in 2 blocks
iconv(UTF8,UTF-16LE) contains 46 bytes in 3 blocks
iconv(UTF-16LE,UTF8) contains 46 bytes in 3 blocks
the numbers are recursive summaries for all the memory hanging off each context.
this option is not thread safe when used, but the code is thread safe
if the option is not given, so I don't think thats a problem.
const warnings for a long time, and no real way to approach a
solution. Some of them are unavoidable due to the way the C standard
works (for example, any function that provides strchr() like
functionality _must_ produce a const warning)
I will be converting a bunch of places that currently produce const
warnings to use the discard_const_p(). Some of these will be
unavoidable const problems, some of them will be ones we will fix up
over time. At least this change means we will no longer be swamped
with const warnings, and we will easily be able to see when new
problems emerge.
server code. This fixes a number of memory leaks I found when testing
with valgrind and smbtorture, as the cascading effect of a
talloc_free() ensures that anything derived from the top level object
is destroyed on disconnect.
