"Queries(WQL)" and "Queries(CQL)" via omicli with "-u HostName\root" and "-synchronous" option should return correct data

[Wayenyin]

Good result:
Run command without "-synchronous":

 /opt/omi/bin/omicli -u root -p *** --auth NegoWithCreds --hostname omi64-cent7-01  --port 5985 --encryption none wql root/omi "select * from MSFT_President"
 instance of MSFT_President
 {
    Key=1
    First=George
    Last=Washington
 }
 instance of MSFT_President
 {
    Key=2
    First=John
    Last=Adams
 }

Issue:
Run command with "-synchronous":

 /opt/omi/bin/omicli -u root -p *** --auth NegoWithCreds --hostname omi64-cent7-01  --port 5985 --encryption none -synchronous  wql root/omi "select * from MSFT_President"
 instance of MSFT_President
 {
    Key=2
    First=John
    Last=Adams
 }
 /opt/omi/bin/omicli: result: MI_RESULT_FAILED
 instance of OMI_Error
 {
    OwningEntity=OMI:CIMOM
    MessageID=OMI:MI_Result:1
    Message=Unknown failure
    MessageArguments={}
    PerceivedSeverity=7
    ProbableCause=0
    ProbableCauseDescription=Unknown failure
    CIMStatusCode=1
    OMI_Code=1
    OMI_Category=0
    OMI_Type=MI
    OMI_ErrorMessage=A general error occurred, not covered by a more specific error code.
 }

Build：omi-1.2.0-84.x86_64

Actual: output "MI_RESULT_FAILED"
Expect: output should be correct.

[paulcallen]

I can see this error when using Basic Auth, and the namespace has to be root/cimv2, not root/omi as in a typical debug build is it not registered in that namespace. It is also not registered normally on a release build either!
More specifically, on a debug build I see a debug assertion showing that we are posting an error to the strand from the transport when the transport has not acknowledged the receipt of the previous message.

(gdb) thread apply all bt

Thread 3 (Thread 0x7f826b54f700 (LWP 156459)):
#0  0x00007f826c60e827 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x7f82640008e8) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem@entry=0x7f82640008e8, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007f826c60e8d4 in __new_sem_wait_slow (sem=0x7f82640008e8, abstime=0x0) at sem_waitcommon.c:181
#3  0x00007f826c60e97a in __new_sem_wait (sem=<optimized out>) at sem_wait.c:29
#4  0x00007f826c87e658 in Sem_Wait (self=0x7f826cb3b440 <s_waitPool+91776>) at sem.h:82
#5  0x00007f826c87eeca in CondLock_Wait (key=20032600, destination=0x131ac88, comparand=0, spinCount=32768) at condlockatomic.c:339
#6  0x00007f826c8478c7 in InteractionProtocolHandler_ThreadShutdown (_application=0x131ac58) at InteractionProtocolHandler.c:2459
#7  0x00007f826c87dfc0 in _Wrapper (param=0x131acd8) at thread.c:221
#8  0x00007f826c6066ba in start_thread (arg=0x7f826b54f700) at pthread_create.c:333
#9  0x00007f826c33c82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 2 (Thread 0x7f826cd49700 (LWP 156458)):
#0  0x00007f826c32c6fd in write () at ../sysdeps/unix/syscall-template.S:84
#1  0x00007f826c2aebff in _IO_new_file_write (f=0x7f826c5fa620 <_IO_2_1_stdout_>, data=0x1320600, n=20) at fileops.c:1263
#2  0x00007f826c2b0409 in new_do_write (to_do=20, data=0x1320600 "    Last=Washington\nsident\n\001", fp=0x7f826c5fa620 <_IO_2_1_stdout_>) at fileops.c:518
#3  _IO_new_do_write (fp=0x7f826c5fa620 <_IO_2_1_stdout_>, data=0x1320600 "    Last=Washington\nsident\n\001", to_do=20) at fileops.c:494
#4  0x00007f826c2af47d in _IO_new_file_xsputn (f=0x7f826c5fa620 <_IO_2_1_stdout_>, data=<optimized out>, n=1) at fileops.c:1331
#5  0x00007f826c283241 in _IO_vfprintf_internal (s=0x7f826c5fa620 <_IO_2_1_stdout_>, format=0x7fff0be544a0 "\n", ap=0x7fff0be54560) at vfprintf.c:1320
#6  0x000000000040bfe5 in Vfprintf (os=0x7f826c5fa620 <_IO_2_1_stdout_>, format=0x42f409 "\n", ap=0x7fff0be54560) at format.c:146
#7  0x000000000040bd11 in Fprintf (os=0x7f826c5fa620 <_IO_2_1_stdout_>, format=0x42f409 "\n") at format.c:83
#8  0x000000000041a8c0 in Instance_Print (self_=0x7f825c01fbb8, os=0x7f826c5fa620 <_IO_2_1_stdout_>, level=1, showNulls=0 '\000', isClass=0 '\000') at instanceprint.c:88
#9  0x0000000000404be5 in ConsumeInstanceResults (miOperation=0x7fff0be547c0) at cli_c.c:736
#10 0x0000000000405cd9 in Query (miSession=0x7fff0be548d0, argc=4, argv=0x7fff0be54a88) at cli_c.c:1231
#11 0x00000000004095b3 in climain (argc=4, argv=0x7fff0be54a88) at cli_c.c:2864
#12 0x0000000000409c34 in main (argc=17, argv=0x7fff0be54a88) at climain_c.c:28

Thread 1 (Thread 0x7f826ab3c700 (LWP 156460)):
#0  0x00007f826c26b428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f826c26d02a in __GI_abort () at abort.c:89
#2  0x00007f826c263bd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x7f826c8ec4fa "!info->thisAckPending", file=file@entry=0x7f826c8ec4d2 "../base/Strand.h", line=line@entry=513, function=function@entry=0x7f826c8ed270 <__PRETTY_FUNCTION__.11947> "_Strand_Post_CommonImp") at assert.c:92
#3  0x00007f826c263c82 in __GI___assert_fail (assertion=0x7f826c8ec4fa "!info->thisAckPending", file=0x7f826c8ec4d2 "../base/Strand.h", line=513, function=0x7f826c8ed270 <__PRETTY_FUNCTION__.11947> "_Strand_Post_CommonImp") at assert.c:101
#4  0x00007f826c889c48 in _Strand_Post_CommonImp (info=0x1322c58, msg=0x7f825c023a70) at ../base/Strand.h:513
#5  0x00007f826c889cd4 in _Strand_PostAndLeaveStrand_Imp (strand=0x1322c08, info=0x1322c58, msg=0x7f825c023a70) at ../base/Strand.h:553
#6  0x00007f826c889e80 in Strand_PostAndLeaveStrand (strand=0x1322c08, msg=0x7f825c023a70) at ../base/Strand.h:1061
#7  0x00007f826c88ce77 in _WsmanClient_Aux_PostMsg (self_=0x1322c08) at wsmanclient.c:1136
#8  0x00007f826c86d4a8 in _StrandMethod_Aux0 (self=0x1322c08) at strand.c:747
#9  0x00007f826c873643 in _Strand_ExecuteLoop (self=0x1322c08, state=4097) at strand.c:2874
#10 0x00007f826c8747a2 in _Strand_ScheduleImp (self=0x1322c08, methodBit=4096, allowMultiSchedule=0 '\000', fromStrand=0x0, entryOperationBit=0) at strand.c:3036
#11 0x00007f826c88a1c9 in Strand_ScheduleAux (self=0x1322c08, auxMethodNumber=0) at ../base/Strand.h:1733
#12 0x00007f826c88a74d in PostResult (self=0x1322c00, message=0x0, result=MI_RESULT_FAILED, cause=0x7f826ab3bd30) at wsmanclient.c:120
#13 0x00007f826c88a9b6 in HttpClientCallbackOnStatusFn2 (http=0x1320348, callbackData=0x1322c00, result=MI_RESULT_FAILED, text=0x0, pcause=0x7f826ab3bd30) at wsmanclient.c:202
#14 0x00007f826c8a793d in _RequestCallback (sel=0x1320350, handlerIn=0x1325c78, mask=32, currentTimeUsec=1492713837799360) at httpclient.c:1475
#15 0x00007f826c87c009 in Selector_Run (self=0x1320350, timeoutUsec=0, noReadsMode=0 '\000') at ../sock/selector.c:1104
#16 0x00007f826c8ab02b in HttpClient_Run (self=0x1320348, timeoutUsec=0) at httpclient.c:3033
#17 0x00007f826c88d7c3 in WsmanClient_Run (self=0x1322c00, timeoutUsec=0) at wsmanclient.c:1468
#18 0x00007f826c843750 in InteractionProtocolHandler_Protocol_RunThread (_operation=0x1320188) at InteractionProtocolHandler.c:994
#19 0x00007f826c87dfc0 in _Wrapper (param=0x1326378) at thread.c:221
#20 0x00007f826c6066ba in start_thread (arg=0x7f826ab3c700) at pthread_create.c:333
#21 0x00007f826c33c82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

I think the race condition is coming because the transport posted the instance to the C API and is being dumped to the screen in OMICLI. In the mean time the server dumped the connection and triggered a callback that is causing us to post an error because it thinks we have not processed the results properly yet, which is only partially true -- we have posted the final result but don't have the ack from the client yet.

[palladia]

Fixed with #294