2022年6月和7月的工作经历

6月

3D打标软件

3D打标软件，要求在Open3d上加几个2D文字。大致有如下几个方案：

依葫芦画瓢，但O3DVisualizer派生于gui::Window，我的程序派生于Visualizer。工作量不小。

利用OpenGL输出文字，Baidu的两种方法一个编译不过，一个根本就没效果。

利用Window API输出文字，本机上没问题。有两台机器显示高几率丢失。原因位置，可能是本机是集成显卡，那两台是独立显卡。

蹉跎一天多，最终利用Window API创建了几个Static显示文字。

同一个函数多线程执行时间

函数结束时间减去开始时间就是执行时间，如果是多线程，必须同一线程同一函数的结束时间减去同一线程同一函数的开始时间。手工计算太麻烦，于是写了个小工具。试用了一天发现，除了忘记限制同一线程，无其它问题。修正后，就好了。工具修正后，就不会出错了，手动计算这次没错不代表下次不出错。

7月

1.try

项目属性，加上 /EHa 后，可以try 到 catch (...) 我所知的所有异常，建议__try，这样可以得到崩溃时的堆栈。我实验了60种组合，5种C#调用方式（主线程、委托、线程、任务、线程池）、3种崩溃方式（本线程崩溃、AfxBeginThread崩溃、std::thread线程崩溃）、4类常见异常：

一，int* p = NULL;

*p = 3;

二，std::string str(NULL);

三， class Polymorphic { virtual void member() {} };

Polymorphic* p = NULL;

typeid(*p);

四，throw(1);

事后补充：CreateThread 也可以。

2.阴沟翻船

周五自己封装托管C++库，在用户的机器上启动不了。demo也是如此，情况如下：

一，托管C++和C# .netframe4.5，C++ 工具集v142。

二，传统c++的exe和dll都可以正常运行，C#的exe和C#的dll都是可以正常运行。

三，exe改成托管，也可运行。

用depend看，发现托管C++库链接了Debug版的运行库，改成MDd就好了。

猜测：

增加配置v142时复制了Debug而不是Release。

3.向日葵与VM冲突

这两天发现VM不好用了，顶部悬浮工具栏不出来，alt+tab 多次才能到主机，无法从虚拟机复制文件到主机。可惨了，重启虚拟机都没用，只能重启主机。后来发现切换到主机，把向日葵的远程登陆关掉就好了，虽然还是麻烦，但是好多了。ToDesk似乎和VM不冲突，以前一直用todesk。发到微博后，收到ToDesk官方微博的回复。

4.死锁

和徐永昌谈到死锁，于是完成CCriticalGroup类以避免死锁，此类已经进入公司SVN库。线程一先后锁ab，线程二先后锁bc，线程三先后锁ca。运气不好的时候，3个线程对第一个锁加锁成功，无法对第二个锁加锁，因为已经被其它线程锁定了。

此类功能：

一，如果你按abc的顺序初始化CCriticalGroup类，无论你锁ab，还是锁ba，都是先锁a，再所b。

二，不需要自己维护临界区。

此类声明：

测试用例：

脉脉上有高人指点，std::scoped_lock std::lock std::lock_guard 可以解决死锁。VS2013、VS2015、VS2017不支持，VS2019默认不支持，改成C++17或C++20就支持了。

5.std::thread线程不触发SetUnhandledExceptionFilter

发现std::thread启动的线程崩溃，不触发 SetUnhandledExceptionFilter ，没机会生成dump.txt和转储文件。一直手动__try，今天忙中抽闲研究一下发现std::thread的线程函数声明了noexcept。

6.系统卡死

用户那有部分电脑卡顿，我在测试平台试验了，出现了两次。症状如下：

一，整个操作系统无响应，鼠标、键盘输入无效。

二，windows任务管理器不刷新。

三，系统时间不更新。

四，鼠标上的灯是亮的。拔掉鼠标，再插上，鼠标的灯不亮。利用机箱上“重启键”重启后，鼠标的灯亮了。

无响应时：CPU不到20%，内存不到50%，两块硬盘0%，1%，网卡不到100K。

和perfmon的记录一致。

我们的程序是普通程序，Win10用户态程序有可能把操作系统卡死么？会不会是硬件驱动的问题。

和此产品的主程沟通，他没用使用hook、系统回调、系统钩子之类。但不排除其他程序员无意中使用了，他入职前就已经有这套程序了。

0环就只有一个进程了system，这个进程有近200个线程，我们的工控机是8核，就算回调、钩子有问题也只会卡死少数几个线程啊。应该会变卡，但不会卡死。魏家瑜说驱动层不能同时执行，一个回调卡死整个系统。

7.用户态的程序能卡死操作系统么？

昨天怀疑系统的回调函数会让系统（多核）变卡，但不会完全卡死。今天在Win10（4核）,C#2013实验了一下。

结果：启动20个TestListenDir.exe，修改文件、重命名文件 都不会让系统变卡，更不会卡死。新增加文件，系统变卡，CPU占用100%，TestListenDir.exe每个占用CPU近5%。系统时间正常更新。

using System.IO;
using System.Windows.Forms;
namespace TestListenDir
{
    public partial class Form1 : Form
    {
        class WatcherFTPDir
        {
            public void MonitorDirectory(string path)
            {
                try
                {
                    FileSystemWatcher fileSystemWatcher = new FileSystemWatcher();
                    fileSystemWatcher.IncludeSubdirectories = true;
                    fileSystemWatcher.Path = path;
                    fileSystemWatcher.Created += FileSystemWatcher_Created;
                    fileSystemWatcher.Changed += FileSystemWatcher_Changed;
                    fileSystemWatcher.Renamed += FileSystemWatcher_Renamed;
                    fileSystemWatcher.EnableRaisingEvents = true;                    
                }
                catch
                {
                }
            }
            private void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
            {
                long iIndex = 0;
                //大约需要7秒
                for (long i = 0; i < (long)10000*1000*1000; i++)
               {
                   iIndex = i;
               }
                MessageBox.Show(iIndex.ToString());
            }
            private void FileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
            {
                MessageBox.Show("修改文件:" + e.FullPath);
            }
            private void FileSystemWatcher_Renamed(object sender, FileSystemEventArgs e)
            {
                System.Threading.Thread.Sleep(1000 * 100);
            }          
        }
        WatcherFTPDir watch = new WatcherFTPDir();
        public Form1()
        {
            InitializeComponent();
            watch.MonitorDirectory("c:\\a");
        }
    }
}

8.程序崩溃,Windows事件查看器看不到

本公司的某产品，在我、客户那可以正常生成自定义异常文件dump.txt，在Windows事件查看器也可以看到崩溃信息。在主程序员那两者皆无。操作系统都是Win10。问题暂未解决。自动覆盖旧日志开启了，所以不是磁盘空间满了。弄了个简单demo，崩溃后，windows事件查看器看得到。

9.Stack buffer overflow

同事的程序崩溃了，我的模块并没生成dump.txt。幸运的是，可以在客户那100%重现，同事自己的机器不重现。只好用WinDbg调试，可以定位崩溃函数名和函数的偏移量和错误类型。第二次崩溃崩溃前，把程序界面尽量往右拉，给wdg留出位置。发现windbg显示了崩溃行，只是被程序界面挡住了。错误类型是：Stack buffer overflow。此类错误最典型的例子：

char  c[1];

strcpy_s(c,"abc1111111111111111111111111111111222");

根据这两条信息，同事找到缺陷，OpenCV版本不对，Mat 的析构函数会崩溃。

10.续

之前就知道 栈溢出（Stack overflow），无法触发UnHand，昨天发现栈缓存溢出（Stack buffer overflow）也无法触发UnHand。今天实验了一下，无论是否/EHa ，这两种溢出都不会触发try __try。 Windows事件查看器会有记录。