This seems a bug. I am trying to remove an existing value in the defaults.
UserDefaults.standard.set(nil, forKey: "test-me")
let val = UserDefaults.standard.object(forKey: "test-me")
print ("val=\(val)")
I got the following output -
val=Optional(<62706c69 73743030 d4010203 04050608 09582476 65727369 6f6e5824 6f626a65 63747359 24617263 68697665 72542474 6f701200 0186a0a1 0755246e 756c6c5f 100f4e53 4b657965 64417263 68697665 72d10a0b 54726f6f 74800008 111a232d 3237393f 51545900 00000000 00010100 00000000 00000c00 00000000 00000000 00000000 00005b>)
I am running in XCode 8 / iOS 10 / iPhone 7 simulator.
The comment from Rob in the other post looks correct. Setting the value to "nil" will save it as NSData. To remove the key, try this instead:
UserDefaults.standard.removeObject(forKey: "test-date")
You will then probably get back "nil" when doing object(forKey: "test-date")
Related
I try to use IMAP object from Chilkat AcitveX component.
$oImap.Login($sImapUserName, $sImapPassword)
ConsoleWrite(#ScriptLineNumber & ' LOGIN: ' &$oImap.LastErrorText & #CRLF)
Returns:
Login:
DllDate: Sep 28 2020
ChilkatVersion: 9.5.0.84
UnlockPrefix: ******************
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
loginX:
greeting: * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot (Debian) ready.
authenticateLogin:
loginImap:
ConnectionType: Unencrypted TCP/IP
--loginImap
isOK:
serverResponse: aaab OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY LITERAL+ NOTIFY SPECIAL-USE QUOTA] Logged in
--isOK
--authenticateLogin
--loginX
Success.
--Login
I use this snippet:
Local $s_refName = ''
Local $s_wildcardedMailbox = '*'
Local $oMBoxes = $oImap.ListMailboxes($s_refName, $s_wildcardedMailbox)
ConsoleWrite(#ScriptLineNumber & ' ' &$oImap.LastErrorText & #CRLF)
Returns:
ListMailboxes:
DllDate: Sep 28 2020
ChilkatVersion: 9.5.0.84
UnlockPrefix: *****
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
listMailboxes:
bSubscribedOnly: 0
reference:
mailbox: *
Escaping quotes and backslashes in mailbox name...
utf7EncodedMailboxPath: *
isOK:
serverResponse: aaac OK List completed (0.016 + 0.000 + 0.015 secs).
--isOK
Success.
--listMailboxes
Success.
--ListMailboxes
Problem description:
I try to get Listboxes collection object but I do not get properly collections of objects.
If I check it like this:
ConsoleWrite('! ' & IsObj($oMBoxes) & #CRLF)
RESULT: ! 0
ConsoleWrite('! ' & VarGetType($oMBoxes) & #CRLF)
RESULT: ! Object
ConsoleWrite('! ' & $oMBoxes.Count)
RESULT: from COM Error Handler I get:
err.number is: 0x00000004
err.windescription: NULL Pointer assignment
eventually using diffrent version of AutoIt I get:
err.number is: 0x00000003
err.windescription: Object Invoke failed
Question:
Any idea of the cause of the problem?
Registering object by using:
regsvr32 ChilkatAx-9.5.0-win32.dll
Fix this issue.
Can someone explain why the following code yields different results on the second printf if I comment the first printf line or not, in 64 bits?
/* gcc -O0 -o test test.c */
#include <stdio.h>
#include <stdlib.h>
int main() {
char a[20] = {0};
char b = 'a';
int count=-1;
// printf("%.16llx %.16llx\n", a, &b);
printf("%x\n", *(a+count));
return 0;
}
I get the following results for the second printf:
commented: 0
uncommented: 61
Thanks in advance!
iansus
Can someone explain why the following code yields different results on the second printf if I comment the first printf line or not
Your program uses a[-1], and thus exhibits undefined behavior. Anything can happen, and figuring out exactly why one or the other thing happenes is pointless.
The precise reason is that you are reading memory that gets written to by the first printf (when commented in).
I get a different result (which is expected with undefined behavior):
// with first `printf` commented out:
ffffffff
// with it commented in:
00007fffffffdd20 00007fffffffdd1b
ffffffff
You could see where that memory is written to by setting a GDB watchpoint on it:
(gdb) p a[-1]
$1 = 0 '\000'
(gdb) p &a[-1]
$2 = 0x7fffffffdd1f ""
(gdb) watch *(int*)0x7fffffffdd1f
Hardware watchpoint 4: *(int*)0x7fffffffdd1f
(gdb) c
Continuing.
Hardware watchpoint 4: *(int*)0x7fffffffdd1f
Old value = 0
New value = 255
main () at t.c:12
12 printf("%.16llx %.16llx\n", a, &b);
It my case above, the value is written as part of initializing count=-1. That is, with my version of gcc, count is located just before a[0]. But this may depend on compiler version, exactly how this compiler was built, etc. etc.
I have dump of w3wp process (taken by procdump) where I see strange situation.
Simplified version on my code:
logger.Log(Thread.CurrentThread.ManagedThreadId);
using(semaphore_release_on_dispose_object)
{
// some third party code with unmanaged parts
DangerousCode();
}
semaphore_release_on_dispose_object - release semaphore in Dispose.
Process dump was taken after some timeout, when it was clear that semaphore was not released
I found thread in dump, but it seems become 'bad'. It listed by ~ command, but not listed by !threads command. When I switch to it I can see unmanaged stack, but not managed:
0:004> ~
...
3 Id: 63ec.11b0 Suspend: 1 Teb: 000007ff`fffae000 Unfrozen
...
0:004> ~~[11b0]s
ntdll!NtRemoveIoCompletion+0xa:
00000000`76e913aa c3 ret
0:003> k
# Child-SP RetAddr Call Site
00 00000000`01a3f818 000007fe`fcea169d ntdll!NtRemoveIoCompletion+0xa
01 00000000`01a3f820 00000000`76d2a4e1 KERNELBASE!GetQueuedCompletionStatus+0x39
02 00000000`01a3f880 000007fe`f0311f7b kernel32!GetQueuedCompletionStatusStub+0x11
03 00000000`01a3f8c0 000007fe`f0312024 w3tp!THREAD_POOL_DATA::ThreadPoolThread+0x3b
04 00000000`01a3f910 000007fe`f03120a1 w3tp!THREAD_POOL_DATA::ThreadPoolThread+0x34
05 00000000`01a3f940 00000000`76d3652d w3tp!THREAD_MANAGER::ThreadManagerThread+0x61
06 00000000`01a3f970 00000000`76e6c521 kernel32!BaseThreadInitThunk+0xd
07 00000000`01a3f9a0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d
0:003> !clrstack
OS Thread Id: 0x11b0 (3)
Child SP IP Call Site
GetFrameContext failed: 1
0000000000000000 0000000000000000
So, I assume that somehow third party code some how 'broke' thread and skip finally block (using).
Any ideas how it is possible?
This might be my misunderstanding of how parsers reduce rather than a potential bug in SQLite's lemon parser. I have been experimenting with simple grammars for a database input file. The database consists of a list of at least one entry sets, things like "commands", or "maps" or...
Here's a grammar that does not work - I have started creating the entry sets and so far all I have is a "command":
database ::= entrylist.
entrylist ::= entrylist entryset.
entrylist ::= entryset.
entryset ::= command.
/* Commands are in the form %command [arguments] \n */
command ::= CMDNAME cmdargs EOL.
cmdargs ::= cmdargs cmdarg.
cmdargs ::= .
cmdarg ::= INTEGER.
cmdarg ::= TEXT.
If I run this with a test program that just feeds in tokens I get:
$ test
Debug: Input 'CMDNAME'
Debug: Shift 'CMDNAME', go to state 3
Debug: Return. Stack=[CMDNAME]
Debug: Input 'INTEGER'
Assertion failed: stateno <= YY_SHIFT_COUNT, file testpar.c, line 513
If I give the entryset an additional alternative:
entryset ::= command.
entryset ::= map.
...
map ::= MAPNAME EOL.
then the whole thing works as expected. I think perhaps you aren't allowed create a situation where a::=b and b::=c. You must have b ::= c | d at the very least. I'd like to understand if this is my mistake in understanding.
Lemon compresses the shift table to remove default actions from the end of the table. Presumably, default actions should be handled elsewhere but they aren't. Your example happens to have default actions so the table is compressed, YY_MAX_SHIFT and YY_SHIFT_COUNT are out of sync, and the assert is triggered.
In lemon.c, around line 4235, you can comment out this line:
while( n>0 && lemp->sorted[n-1]->iTknOfst==NO_OFFSET ) n--;
to prevent compression and to prevent the bug.
Generated code with compression:
#define YY_MAX_SHIFT 3
#define YY_SHIFT_COUNT (2)
#define YY_SHIFT_USE_DFLT (13)
static const unsigned char yy_shift_ofst[] = {
/* 0 */ 7, 1, 6,
};
Generated code without compression:
#define YY_MAX_SHIFT 3
#define YY_SHIFT_COUNT (3)
#define YY_SHIFT_USE_DFLT (13)
static const unsigned char yy_shift_ofst[] = {
/* 0 */ 7, 1, 6, 13,
};
I submitted the details to the SQLite mailing list earlier this year but nothing has happened yet. The correct solution is probably to continue compressing but handle default actions in the template.
Bug logged to SQLite mailing list:
http://www.mail-archive.com/sqlite-users#mailinglists.sqlite.org/msg99712.html
http://www.mail-archive.com/sqlite-users#mailinglists.sqlite.org/msg99716.html
Hi
I am running a bi-di 'iperf' test on an interface using my driver.
Steps to repro would be to run bi-di I/O on one interface(other interface is not active):
Run iperf -c -P 8 -t 100000 -I 10 on DUT
iperf -c with same params as above from peer almost immediately ( after 1st 10s of above 'iperf send' are over)
With 'iperf -s -w 256K' on both
The crash is not happening as such in the driver but in the 'iperf' context. I am going to copy-paste the stack trace:
PID: 8855 TASK: f7036550 CPU: 0 COMMAND: "iperf"
#0 [c074bed0] crash_kexec at c0443233
#1 [c074bf14] die at c04064d3
#2 [c074bf44] do_page_fault at c062134b
#3 [c074bf94] error_code (via page_fault) at c0405abb
EAX: f5888100 EBX: 00000000 ECX: 00100100 EDX: 00200200 EBP: 00000001
DS: 007b ESI: f5888000 ES: 007b EDI: cb614000
CS: 0060 EIP: c05c4e94 ERR: ffffffff EFLAGS: 00010046
#4 [c074bfc8] net_rx_action at c05c4e94
#5 [c074bfe4] __do_softirq at c042aa65
--- <soft IRQ> ---
#0 [f281ac4c] do_softirq at c04073e5
#1 [f281ac58] do_IRQ at c04074d9
#2 [f281ac70] common_interrupt at c0405975
EAX: 39383736 EBX: f281af4c ECX: 00000428 EDX: 31303938 EBP: f378b042
DS: 007b ESI: f378b1c2 ES: 007b EDI: 09fdb448
CS: 0060 EIP: c04f1c07 ERR: ffffffba EFLAGS: 00000202
#3 [f281aca4] __copy_to_user_ll at c04f1c07
#4 [f281acb0] memcpy_toiovec at c05bfecc
#5 [f281acc4] skb_copy_datagram_iovec at c05c059b
#6 [f281acf4] tcp_rcv_established at c05ef40a
#7 [f281ad20] tcp_v4_do_rcv at c05f48c5
#8 [f281ad54] tcp_prequeue_process at c05e6bdd
#9 [f281ad5c] tcp_recvmsg at c05e90e2
#10 [f281ad9c] sock_common_recvmsg at c05bb1c4
#11 [f281adc0] sock_recvmsg at c05b8dc6
#12 [f281aea0] sys_recvfrom at c05ba6ab
#13 [f281af64] sys_recv at c05ba727
#14 [f281af80] sys_socketcall at c05bab52
#15 [f281afb8] system_call at c0404f44
EAX: ffffffda EBX: 0000000a ECX: b6ba2340 EDX: 00014268
DS: 007b ESI: 00000000 ES: 007b EDI: 09fbe630
SS: 007b ESP: b6ba2328 EBP: b6ba2378
CS: 0073 EIP: 004ad410 ERR: 00000066 EFLAGS: 00000293
crash>
the EIP at the time of crash is net_rx_action:0xdd/19ca. Now i have compiled the kernel-2.6.18-238 sources( the source version of the OS on which the DUT is running) and did an 'objdump -S ./net/core/dev.o > dev_o_dmp' on the ./net/core/dev.c which has the definition of the net_rx_acdtion(). Now in the 'dev_o_dmp' file the net_rx_action() has lots of inline definitions and hence somehow does not exactly mirror the flow in the source file. In such a scenario ,is it safe to add 0xdd to the base addr of net_rx_action (say 32FF) => 340C .i.e would 340C be the offending line number that is giving rise to the crash ' kernel paging request error'
Any tips /recommendations on how to go about debugging this problem would be of great help
Unfortunately, or fortunately depending on your perspective, with high levels of optimization it is possible for the compiler to create assembly code that the debug format cannot make a reasonable C code line to assembly instruction(s) mapping. What type of cases you can run into this problem depends on the compiler, optimization level, debug symbol format, debug symbol level, and the code itself.
You have to assume that line numbers gained via this technique could be wrong. That being said, I use this technique frequently in my own kernel work and I have not had any problems yet (knocks on wood). Just remember that if you are faced with something that just makes no sense, you could have a bad line number.