Fix “The language server crashed 5 times in the last 3 minutes.” error for VS Code C/C++ extension

From yesterday, My VS Code‘s C/C++ extension always reports “The language server crashed 5 times in the last 3 minutes.” error, and I have tried all the methods: Re-install extension, Re-start machine, re-isntall VS Code, etc. Unfortunatelly, no one works. Finally I install the VS Code - Insiders, then the problem is gone.

Convert pcapng file to pcap format

Today I met another error related to multiple interfaces in pcapng file:

pcap_next_ex() [an interface has a type 0 different from the type of the first interface]. Trace index = 8122

From my previous post, I wanted to convert it to pcap format by tshark command. But unfortunately it didn’t work:

$ tshark -F pcap -r a.pcapng -w b.pcap
tshark: Frame 8122 of file "a.pcapng" has a network type that differs from the network type of earlier packets, which isn't supported in a "Wireshark/tcpdump/... - pcap" file.

I had no choice but stole code from pcapplusplus to implement a converter, and the final code can be downloaded here. Please note on my macOS system, I did little tweak about PcapPlusPlus.mk:

$ cat /opt/homebrew/Cellar/pcapplusplus/22.11/etc/PcapPlusPlus.mk
......
# libs
PCAPPP_LIBS_DIR := -L/opt/homebrew/Cellar/pcapplusplus/22.11/lib
......

The pitfall of upgrading 3rd-party library

Today, I debugged a tricky issue, a bug related to a 3rd-party library. When I used gdb to check a structure’s values, found the last member was missed compared to the definitions in header file. I began to suspect this might be caused by 3rd-party library. I checked the upgrade log, then found the root cause: when I compiled the code, the 3rd-party library’s version is v1.1, but when I run the program, the library was upgraded to v1.2 by others, which caused this mysterious bug. The solution is simple: rebuild the code. But the debugging process is exhausting.

Bisection assert is a good debug methodology

Recently, I fixed an issue which is related to uninitialised bit-field in C programming language. Because the bit-filed can be either 0 or 1, so the bug will occur randomly. But the good news is the reproduced rate is very high, nearly 50%. Though I am not familiar with the code, I used bisection assert to help:

 {
  ......
  assert(bit-field == 0);
  ......
  assert(bit-field == 0);
  ......
 }

If the first assert is not triggered, but the second one is, I can know which code block has the bug, then bisect code and add assert again, until the root cause is found.

badssl.com

Today I discovered badssl.com, a very useful website to test various exceptional TLS/SSL cases. E.g., I tested what will happen if client supports TLS 1.3 only while server supports TLS 1.2 only:

# openssl s_client -connect tls-v1-2.badssl.com:1012 -tls1_3
CONNECTED(00000005)
01000000:error:0A000410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1584:SSL alert number 40
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 253 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---