Still some loose ends after commit ba53e284e68

Christopher O Cowan - Christopher.O.Cowan@ibm.com Christopher.O.Cowan at ibm.com
Mon Jan 13 20:37:11 UTC 2020


Thanks.   That worked.

Now smbd is failing later in the startup.    I'll post details, if I can't figure it out.


On 1/10/20, 5:51 PM, "Jeremy Allison" <jra at samba.org> wrote:

    On Fri, Jan 10, 2020 at 03:34:10PM -0800, Jeremy Allison wrote:
    > On Fri, Jan 10, 2020 at 10:46:54PM +0000, Christopher O Cowan - Christopher.O.Cowan--- via samba-technical wrote:
    > > I still getting some assertions pointing to rec->value_valid after compiling with the patch.   Seems to be when I'm attempting to start smbd.
    > > 
    > > I've attached the log from running smbd -i -d10, and a dbx stack trace.
    > > It appears that there additional callbacks that need to be cleaned up.
    > ..
    > > Type 'help' for help.
    > > [using memory image in /tmp/core.6488334.10223352]
    > > reading symbolic information ...
    > > 
    > > IOT/Abort trap in pthread_kill at 0xd054bb94 ($t1)
    > > 0xd054bb94 (pthread_kill+0xb4) 80410014            lwz   r2,0x14(r1)
    > > pthread_kill(??, ??) at 0xd054bb94
    > > _p_raise(??) at 0xd054afe4
    > > raise.raise(??) at 0xd0121020
    > > abort() at 0xd017cae4
    > > dump_core(), line 338 in "dumpcore.c"
    > > smb_panic_s3(why = "assert failed: rec->value_valid"), line 853 in "util.c"
    > > smb_panic(why = "assert failed: rec->value_valid"), line 174 in "fault.c"
    > > dbwrap_record_get_value(rec = 0x2016e5f8), line 82 in "dbwrap.c"
    > > regdb_upgrade_v2_to_v3_fn(rec = 0x2016e5f8, private_data = 0x2016de28), line 617 in "reg_backend_db.c"
    > > traverse_persistent_callback(tdb = 0x2016e1f8, kbuf = (...), dbuf = (...), private_data = 0x2ff21fd8), line 1581 in "dbwrap_ctdb.c"
    > > unnamed block in tdb_traverse_internal(tdb = 0x2016e1f8, fn = 0xf0570044, private_data = 0x2ff21fd8, tl = 0x2ff21f70), line 222 in "traverse.c"
    > > tdb_traverse_internal(tdb = 0x2016e1f8, fn = 0xf0570044, private_data = 0x2ff21fd8, tl = 0x2ff21f70), line 222 in "traverse.c"
    > > tdb_traverse(tdb = 0x2016e1f8, fn = 0xf0570044, private_data = 0x2ff21fd8), line 295 in "traverse.c"
    > > unnamed block in db_ctdb_traverse(db = 0x2016de28, fn = 0x2004d1f8, private_data = 0x2016de28), line 1647 in "dbwrap_ctdb.c"
    > > db_ctdb_traverse(db = 0x2016de28, fn = 0x2004d1f8, private_data = 0x2016de28), line 1647 in "dbwrap_ctdb.c"
    > > dbwrap_traverse(db = 0x2016de28, f = 0x2004d1f8, private_data = 0x2016de28, count = (nil)), line 377 in "dbwrap.c"
    > > regdb_upgrade_v2_to_v3(db = 0x2016de28), line 706 in "reg_backend_db.c"
    > > regdb_init(), line 829 in "reg_backend_db.c"
    > > registry_init_common(), line 33 in "reg_init_basic.c"
    > > registry_init_full(), line 81 in "reg_init_full.c"
    > > main(argc = 3, argv = 0x2ff2255c), line 2020 in "server.c"
    > 
    > This backtrace is an interesting one.
    
    Never mind - found it :-).
    
    db_ctdb_fetch_locked_transaction() has an early return if
    pull_newest_from_marshall_buffer() returns true, and we
    weren't setting result->value_valid = true there.
    
    Can you try this patch ? I think it'll fix it.
    
    Cheers,
    
    	Jeremy.
    



More information about the samba-technical mailing list