Something wrong with autobuild?

Michael Adam obnox at samba.org
Sat Mar 31 12:47:33 MDT 2012


Not sure about the concrete error, it looks like a wrong type
ends up in private data. Could be some form of event assignment
error.

But if it is unrelated to your changes, then chances are that
that you have hit one of the flakey tests.

You could scan the "autobuild: intermittent test failure
detected" messages on samba-cvs for similarities.
Do you still have the autobuild-log url of your error available?

Anyhow, if you don't see a relationship between your changes and
this error, it is generally worthwile re-trying.
(Do "git commit --amend" before pushing to autobuild again so
that you have a different commit hash...)

Of course we should eventually get rid of all thos flaky tests... :-)

Cheers - Michael

Richard Sharpe wrote:
> On Sat, Mar 31, 2012 at 10:42 AM, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
> > On Sat, Mar 31, 2012 at 10:34 AM, Michael Adam <obnox at samba.org> wrote:
> >> Hi Richard,
> >>
> >> I think it is not a real error but this:
> >>
> >> * the databases are ususally opened without O_CREAT
> >>  first. and only with CREAT when the first open fails.
> >>  Now tdb2 seems to log the failure at a much lower
> >>  debug level than tdb(1), which is why you see it in
> >>  each make test run at least in the first open.
> >>  The second open succeeds and you don't see a
> >>  corresponding success log message.
> >>
> >> * We also see here the fact that the tdb2 log messages
> >>  generally lack a "\n" at the end.. ;)
> >>
> >> * the account policy messages are also harmless. if I get
> >>  it right, these record simply don't exist in the freshly
> >>  created db. This is logged and default values are used
> >>  instead.
> >>
> >> Could this explain the phenomena or are you really seeing failures?
> >
> > Well, I got an autobuild failure and saw those errors so assumed that
> > was the problem since my change did not seem so harmful.
> >
> > I guess I will have to look deeper to see what the problem is.
> 
> Is the following more like an error? It seems to have nothing to do
> with my changes.
> 
> ../source4/rpc_server/handles.c:106: Attempt to use invalid iface
> /memdisk/sharpe/a/b18058/samba4/bin/smbd: Cleaning up brl and lock
> database after unclean shutdown
> /memdisk/sharpe/a/b18058/samba4/bin/smbd: Scheduled cleanup of brl and
> lock database after unclean shutdown
> /memdisk/sharpe/a/b18058/samba4/bin/smbd: Got pipe request (pnum 1129)
> using invalid VUID 101, expected 100
> ndr_pull_error(11): Pull bytes 4 (../librpc/ndr/ndr_basic.c:148)
> ndr_pull_error(11): Pull bytes 4 (../librpc/ndr/ndr_basic.c:148)
> ndr_pull_error(11): Pull bytes 4 (../librpc/ndr/ndr_basic.c:148)
> ../source4/rpc_server/handles.c:106: Attempt to use invalid iface
> /memdisk/sharpe/a/b18058/samba4/bin/smbd: Cleaning up brl and lock
> database after unclean shutdown
> ../source4/libnet/libnet_user.c:801: Type mismatch: name[struct
> wbsrv_connection] expected[struct composite_context]
> smb_panic(): calling panic action
> [/memdisk/sharpe/a/b18058/samba4/selftest/gdb_backtrace 9928]
> [Thread debugging using libthread_db enabled]
> 0x00002af91368f27e in __libc_waitpid (pid=<value optimized out>,
>     stat_loc=0x7fffa27ebbfc, options=<value optimized out>)
>     at ../sysdeps/unix/sysv/linux/waitpid.c:32
> 32	../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> 	in ../sysdeps/unix/sysv/linux/waitpid.c
> #0  0x00002af91368f27e in __libc_waitpid (pid=<value optimized out>,
>     stat_loc=0x7fffa27ebbfc, options=<value optimized out>)
>     at ../sysdeps/unix/sysv/linux/waitpid.c:32
>         oldtype = <value optimized out>
>         result = <value optimized out>
> 
> -- 
> Regards,
> Richard Sharpe
> (何以解憂?唯有杜康。--曹操)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 206 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120331/26eea70c/attachment.pgp>


More information about the samba-technical mailing list