Double free when dealing with the schema

[Matthias Dieter Wallnöfer]

Hi ekacnet,

consider this code snippet (schema_set.c):
>         } else {
>                 p = ldb_get_opaque(ldb, "dsdb_schema");
>
>                 schema_in = talloc_get_type(p, struct dsdb_schema);
>                 if (!schema_in) {
>                         return NULL;
>                 }
>         }
Did you check that the "dsdb_schema" opaque value is set correctly? It 
could be that you open a very old LDB database where it doesn't exist 
yet - then you've to deal with it in the upgrade script.

Greets,
Matthias

Matthieu Patou wrote:
> Hello Andrew and Mathias,
>
> Here is the clear picture on what is happening:
> /scripting/bin/upgradeprovision -s 
> ~/workspace/samba/alpha8/etc/smb.conf --full
> Creating a reference provision
> pdc_fsmo_init: no domain object present: (skip loading of domain details)
>
> naming_fsmo_init: no partitions dn present: (skip loading of naming 
> contexts details)
>
> naming_fsmo_init: no partitions dn present: (skip loading of naming 
> contexts details)
>
> naming_fsmo_init: no partitions dn present: (skip loading of naming 
> contexts details)
>
> Copy privilege
> Copy samdb
> Update partitions filename if needed
> Starting update of samdb
> There are 1577 missing objects
> There are 1583 changed objects
> Update of samdb finished
> update secrets.ldb
> Update machine account
> talloc: double free error - first free may be at ../lib/ldb/pyldb.c:1378
> Bad talloc magic value - double free
> Abandon
>
>
> 0xb7fe2430 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7fe2430 in __kernel_vsyscall ()
> #1  0xb7e544d1 in *__GI_raise (sig=6) at 
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #2  0xb7e57932 in *__GI_abort () at abort.c:92
> #3  0xb7fcf8f8 in talloc_abort (reason=0xb7fd279c "Bad talloc magic 
> value - double free") at ../../lib/talloc/talloc.c:199
> #4  0xb7fcf9af in talloc_abort_double_free () at 
> ../../lib/talloc/talloc.c:218
> #5  0xb7fcfa3e in talloc_chunk_from_ptr (ptr=0xbcaf598) at 
> ../../lib/talloc/talloc.c:239
> #6  0xb7fd0b77 in talloc_get_name (ptr=0xbcaf598) at 
> ../../lib/talloc/talloc.c:945
> #7  0xb7fd0bed in talloc_check_name (ptr=0xbcaf598, name=0xb7b4887f 
> "struct dsdb_schema") at ../../lib/talloc/talloc.c:964
> #8  0xb78e0c51 in dsdb_get_schema (ldb=0xa252d70, reference_ctx=0x0) 
> at ../dsdb/schema/schema_set.c:444
> #9  0xb7a4e1df in resolve_oids_search (module=0xadce8d0, 
> req=0xd407cb0) at ../dsdb/samdb/ldb_modules/resolve_oids.c:467
> #10 0xb7a9b5a0 in ldb_request (ldb=0xa252d70, req=0xd407cb0) at 
> ../lib/ldb/common/ldb.c:779
> #11 0xb7d57b3e in py_ldb_search (self=0x845c93c, args=0xb7de802c, 
> kwargs=0x845a714) at ../lib/ldb/pyldb.c:1154
> #12 0x080dcdc1 in PyEval_EvalFrameEx ()
> #13 0x080dd384 in PyEval_EvalFrameEx ()
> #14 0x080dddf2 in PyEval_EvalCodeEx ()
> #15 0x080ddef7 in PyEval_EvalCode ()
> #16 0x080faa1f in PyRun_FileExFlags ()
> #17 0x080fac12 in PyRun_SimpleFileExFlags ()
> #18 0x0805c8d8 in Py_Main ()
> #19 0x0805baeb in main ()
>
>
> So it's happening when you are upgrading a quite old provision (when 
> the schema changes are important enough to trigger schema reload in 
> next ldb requests.
>
> To trigger this you need the following patches:
> 0001-s4-upgrade-provision-Refactor-code-to-do-all-the-mod.patch
> 0002-s4-Add-functions-related-to-ldb-manipulation-when-do.patch
>
> Please note that I found a workaround by opening the schema more earlier.
>
> Matthieu