Bug 6745 - Segfault while opening an ldb with python bindings
Summary: Segfault while opening an ldb with python bindings
Status: RESOLVED INVALID
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
URL:
Keywords:
Depends on:
Blocks: 6600
  Show dependency treegraph
 
Reported: 2009-09-19 05:44 UTC by Matthieu Patou
Modified: 2009-11-12 04:43 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthieu Patou 2009-09-19 05:44:46 UTC
The problem occurs in the upgradeschema script.
Calls where OK up to the revision 33160b1a5b2bc498f0dfb5c59d0ec0592cc37e8d.
Now with c2139e8e5646a8558d70c1ca4ce2d755497de8e1 I have the following backtrace:

Program received signal SIGSEGV, Segmentation fault.
0xb761d742 in replmd_start_transaction (module=0xa03ff50) at dsdb/samdb/ldb_modules/repl_meta_data.c:2245
2245		talloc_free(replmd_private->la_ctx);
(gdb) bt
#0  0xb761d742 in replmd_start_transaction (module=0xa03ff50) at dsdb/samdb/ldb_modules/repl_meta_data.c:2245
#1  0xb766cb17 in partition_start_trans (module=0x9ea8388) at dsdb/samdb/ldb_modules/partition.c:678
#2  0xb7601aa3 in ldb_next_start_trans (module=0x9ea8388) at lib/ldb/common/ldb_modules.c:604
#3  0xb767c17a in linked_attributes_start_transaction (module=0xa10c838) at dsdb/samdb/ldb_modules/linked_attributes.c:1202
#4  0xb75f8949 in ldb_transaction_start (ldb=0x9ea8ca8) at lib/ldb/common/ldb.c:325
#5  0xb75f8e46 in ldb_autotransaction_request (ldb=0x9ea8ca8, req=0xaba94b8) at lib/ldb/common/ldb.c:487
#6  0xb75fa603 in ldb_modify (ldb=0x9ea8ca8, message=0xacfb648) at lib/ldb/common/ldb.c:1247
#7  0xb769d264 in samdb_replace (sam_ldb=0x9ea8ca8, mem_ctx=0xac87e78, msg=0xacfb648) at dsdb/common/util.c:1000
#8  0xb769153c in dsdb_schema_set_attributes (ldb=0x9ea8ca8, schema=0xad41a10, write_attributes=true) at dsdb/schema/schema_set.c:138
#9  0xb7691e86 in dsdb_set_schema (ldb=0x9ea8ca8, schema=0xad41a10) at dsdb/schema/schema_set.c:357
#10 0xb76801b5 in schema_fsmo_init (module=0xa0402b0) at dsdb/samdb/ldb_modules/schema_fsmo.c:158
#11 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa0402b0) at lib/ldb/common/ldb_modules.c:383
#12 0xb766e99b in partition_init (module=0x9ea8388) at dsdb/samdb/ldb_modules/partition.c:1354
#13 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0x9ea8388) at lib/ldb/common/ldb_modules.c:383
#14 0xb7601a26 in ldb_next_init (module=0x9ea8388) at lib/ldb/common/ldb_modules.c:598
#15 0xb766b3a1 in show_deleted_init (module=0x9ea8738) at dsdb/samdb/ldb_modules/show_deleted.c:113
#16 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0x9ea8738) at lib/ldb/common/ldb_modules.c:383
#17 0xb7601a26 in ldb_next_init (module=0x9ea8738) at lib/ldb/common/ldb_modules.c:598
#18 0xb76754e7 in extended_dn_out_ldb_init (module=0x9ea8b78) at dsdb/samdb/ldb_modules/extended_dn_out.c:561
#19 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0x9ea8b78) at lib/ldb/common/ldb_modules.c:383
#20 0xb7601a26 in ldb_next_init (module=0x9ea8480) at lib/ldb/common/ldb_modules.c:598
#21 0xb76207a6 in operational_init (ctx=0x9ea8518) at dsdb/samdb/ldb_modules/operational.c:324
#22 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0x9ea8518) at lib/ldb/common/ldb_modules.c:383
#23 0xb7601a26 in ldb_next_init (module=0x9eaaa08) at lib/ldb/common/ldb_modules.c:598
#24 0xb76179cb in kludge_acl_init (module=0xa10c900) at dsdb/samdb/ldb_modules/kludge_acl.c:511
#25 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10c900) at lib/ldb/common/ldb_modules.c:383
#26 0xb7601a26 in ldb_next_init (module=0xa10c900) at lib/ldb/common/ldb_modules.c:598
#27 0xb7679909 in samldb_init (module=0xa10c998) at dsdb/samdb/ldb_modules/samldb.c:2062
#28 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10c998) at lib/ldb/common/ldb_modules.c:383
#29 0xb7601a26 in ldb_next_init (module=0xa10cc40) at lib/ldb/common/ldb_modules.c:598
#30 0xb761e550 in asq_init (module=0xa10cce0) at lib/ldb/modules/asq.c:399
#31 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10cce0) at lib/ldb/common/ldb_modules.c:383
#32 0xb7601a26 in ldb_next_init (module=0xa10cce0) at lib/ldb/common/ldb_modules.c:598
#33 0xb7612be9 in server_sort_init (module=0xa10cd70) at lib/ldb/modules/sort.c:345
#34 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10cd70) at lib/ldb/common/ldb_modules.c:383
#35 0xb7601a26 in ldb_next_init (module=0xa10ce98) at lib/ldb/common/ldb_modules.c:598
#36 0xb7672f5c in paged_request_init (module=0xa10cf30) at lib/ldb/modules/paged_results.c:415
#37 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10cf30) at lib/ldb/common/ldb_modules.c:383
#38 0xb7601a26 in ldb_next_init (module=0xa10cf30) at lib/ldb/common/ldb_modules.c:598
#39 0xb767f88a in rootdse_init (module=0xa10cfc8) at dsdb/samdb/ldb_modules/rootdse.c:445
#40 0xb76010ec in ldb_init_module_chain (ldb=0x9ea8ca8, module=0xa10cfc8) at lib/ldb/common/ldb_modules.c:383
#41 0xb76014a8 in ldb_load_modules (ldb=0x9ea8ca8, options=0x0) at lib/ldb/common/ldb_modules.c:465
#42 0xb75f870e in ldb_connect (ldb=0x9ea8ca8, url=0xa13c934 "/home/mat/eurocopter/testup/private/sam.ldb", flags=0, options=0x0) at lib/ldb/common/ldb.c:241
#43 0xb75f35f5 in py_ldb_connect (self=0xa163464, args=0xb7db002c, kwargs=0xa15de84) at lib/ldb/pyldb.c:633
Comment 1 Matthieu Patou 2009-09-19 07:45:03 UTC
Using ldbedit -H sam.ldb produce also a segfault on the same error.
Comment 2 Matthias Dieter Wallnöfer 2009-10-02 14:14:56 UTC
Does this still happen?
Comment 3 Matthieu Patou 2009-10-04 15:21:20 UTC
Yes still the case with dac0346906b7494f203e1e56b8f2e18c93fc2912 revision.
Comment 4 Matthias Dieter Wallnöfer 2009-10-15 04:43:13 UTC
Ekacnet, I identified your problem now: you have the "schema_fsmo" module inserted before the new "repl_meta_data" module in the LDB modules list. To be right you have to change it to be the opposite ("repl_meta_data" before "schema_fsmo") since "schema_fsmo" has an init function: this init function performs modify operations through a call of "dsdb_schema_set_attributes". Behind stays the "repl_meta_data" module which is launched due to the modify call but isn't initialised yet. It tries to get his configuration context (replmd_private->la_ctx) but fails since it isn't initalised yet and therefore SIGSEGVs.

So this is not really a bug of s4 itself but of the "upgradeschema" script. So I would close this after your permission.
Comment 5 Matthias Dieter Wallnöfer 2009-11-12 04:43:09 UTC
I think this bug is not valid for a standard (unchanged) s4 environment. So I close this for now with "INVALID".