Double free when dealing with the schema

Matthieu Patou mat at matws.net
Thu Apr 22 01:55:49 MDT 2010


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s4-upgrade-provision-Refactor-code-to-do-all-the-mod.patch
Type: text/x-patch
Size: 51819 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100422/d56c37a5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-s4-Add-functions-related-to-ldb-manipulation-when-do.patch
Type: text/x-patch
Size: 6181 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100422/d56c37a5/attachment-0001.bin>


More information about the samba-technical mailing list