The Samba-Bugzilla – Bug 334
net rpc samdump segfaults when dumping the privs database
Last modified: 2005-08-24 10:25:49 UTC
On Wed, 20 Aug 2003, Ronan Waide wrote:
> On August 20, firstname.lastname@example.org said:
> > On August 20, email@example.com said:
> > >
> > > woohoo! also appears to have been solved.
> > oh, except that net rpc samdump still segfaults when dumping the privs
> > database. I've looked at packet traces and core dumps of this in the
> > past and I'm still not sure what's going on.
> Here's a stacktrace:
> #0 0x080a66ed in prs_uint16 (name=0x818d936 "revision ", ps=0xbffff660,
> depth=4, data16=0x19d9c8) at rpc_parse/parse_prs.c:597
> #1 0x080aa585 in sec_io_desc (desc=0x8198ef0 "sec_desc", ppsd=0x82dc8ac,
> ps=0xbffff660, depth=4) at rpc_parse/parse_sec.c:718
> #2 0x080c7957 in net_io_sam_trustdoms_info (desc=0x8197e1c "",
> info=0x82dc8a8, ps=0xbffff660, depth=3) at rpc_parse/parse_net.c:2467
> #3 0x080c86f3 in net_io_sam_delta_ctr (desc=0x8197e1c "",
> sess_key=0x82a8fe4 "\035^[%G^[$,3u=^[^[(B%@')^[%G^[$,3u=u=^[^[(B%@\r",
> ps=0xbffff660, depth=2) at rpc_parse/parse_net.c:2730
> #4 0x080c8b03 in net_io_r_sam_sync (desc=0x81b2e7b "",
> sess_key=0x82a8fe4 "\035^[%G^[$,3u=^[^[(B%@')^[%G^[$,3u=u=^[(B^[%@\r",
r_s=0xbffff5e0, ps=0xbffff660, depth=1)
> at rpc_parse/parse_net.c:2826
> #5 0x08153b73 in cli_netlogon_sam_sync (cli=0x82a8308, mem_ctx=0x82cd780,
> ret_creds=0xbffff750, database_id=2, next_rid=0, num_deltas=0xbffff70c,
> hdr_deltas=0xbffff714, deltas=0xbffff710) at rpc_client/cli_netlogon.c:391
> #6 0x08077157 in dump_database (cli=0x82a8308, db_type=2,
> ret_creds=0xbffff750) at utils/net_rpc_samsync.c:182
> #7 0x08077429 in rpc_samdump (argc=0, argv=0x81d2e7c)
> at utils/netOn Wed, 20 Aug 2003, Ronan Waide wrote:
It was actually a problem unmarshalling the trusted domain info delta which was
obscuring a problem unmarshalling the secret info delta.
The easiest thing at the moment it to comment out these functions as they
seriously don't correspond with reality (netmon/ethereal) and the data in the
containers aren't used anyway.
originally reported against one of the 3.0.0rc[1-4] releases.
Cleaning up non-production versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.