So, watch what happens as I step through the loop in
mapi_nameid_unmap_SPropTagArray, when called from inside GetProps...
(gdb) n
742
SPropTagArray->aulPropTag[mapi_nameid->entries[i].position] = (enum
MAPITAGS) mapi_nameid->entries[i].proptag;
(gdb)
740 for (i = 0; i < mapi_nameid->count; i++) {
(gdb)
741 if (mapi_nameid->entries[i].position <=
SPropTagArray->cValues) {
*** I am still in the loop. Let's just check the entry to hand.
(gdb) p mapi_nameid->entries[i]
$98 = {
proptag = 2182480130,
OOM = 0x7f9e8b43e681 "ApptRecur",
lid = 33302,
Name = 0x0,
propType = 258,
ulKind = 0 '\000',
OLEGUID = 0x7f9e8b43e578 "00062002-0000-0000-c000-000000000046",
position = 13
}
*** Notice the position in this entry 13, so let's just check what is
in the output array at position 13, and confirm it is different than
the proptag in the entry:
(gdb) p SPropTagArray.aulPropTag[13]
$99 = -2112487166
(gdb) p mapi_nameid->entries[i].proptag
$100 = 2182480130
(gdb) n
742
SPropTagArray->aulPropTag[mapi_nameid->entries[i].position] = (enum
MAPITAGS) mapi_nameid->entries[i].proptag;
(gdb)
740 for (i = 0; i < mapi_nameid->count; i++) {
*** That should have updated entry 13 with the proptag, right? Except
it has not changed it at all...
(gdb) p SPropTagArray.aulPropTag[13]
$101 = -2112487166
*** Hmmm maybe this is just the usual inlining/gdb issue, so lets step
right out of this and check again:
(gdb) n
746 return MAPI_E_SUCCESS;
(gdb) p SPropTagArray.aulPropTag[13]
$102 = -2112487166
(gdb) n
747 }
(gdb)
GetProps (obj=0x28d1310, flags=2147483648, SPropTagArray=0x28d1340,
lpProps=0x28d1300, PropCount=0x28d1308) at libmapi/IMAPIProp.c:162
162 talloc_free(nameid);
(gdb) p SPropTagArray.aulPropTag[13]
$103 = -2112487166
(gdb)
*** and so on.
The net result is that mapi_nameid_unmap_SPropTagArray is a no-op on
all my PidLidXxx properties. I hate to blame the compiler, but...any
different ideas?
_______________________________________________
devel mailing list
devel@lists.openchange.org
http://mailman.openchange.org/listinfo/devel
