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