半个多世纪来,计算机技术飞速发展,应用软件的规模也随之愈发庞大,越来越复杂。然而不幸的是,软件规模激增的同时不可避免地引入了越来越多的安全漏洞和缺陷。尽管软件工程一直在努力,遗憾的是,我们不得不面对这样一个事实,“完美的应用软件”一直没有存在过,软件或多或少都存在有Bug。面对软件的不完美之处,大量的更新程序或者补丁被发布,用于弥补漏洞,修补程序缺陷,抑或是用于增强软件功能,我们在此统称之为软件更新。传统软件更新工作在“停机—更新软件—重启”的模式下进行,这种方法势必会导致应用软件服务中断,影响软件的可用性。然而,许多的应用软件服务却对不间断运行有很高的要求,希望能够提供24小时~*7天的全覆盖服务[1],常见于关系民生国计的重要行业中。如果因为各种原因导致这些服务中断的话,带来的损失是惊人的。为了解决软件的可用性与传统软件更新所导致的服务中断之间的矛盾,各类使用不同技术路线的软件动态更新被提出。但是,大部分的动态更新方法都建立在被更新软件运行正常的前提假设下。但事实上,由于被更新软件往往本身存在缺陷、瑕疵,或者是软件漏洞面临的外部攻击威胁,很可能在更新时已经存在某些意外的错误状态。通过对国内外近十年来动态更新领域研究成果的学习、整理、分析,我们发现多数动态更新方法缺乏这方面的处理手段。由于大量动态更新方法在更新时机上是依赖于安全点/更新点机制,缺乏对更新过程中错误状态处理的能力;基于组件/模块实现的动态更新在更新单元上满足不了修复错误状态;基于软硬件冗余的动态更新,由于需要严格保持状态的一致性,对于修复错误状态的支持几乎没有。POLUS动态更新框架使用了与大多数现存方法不同的技术路线,允许新旧数据同时并存,由POLUS框架来保证状态的一致性,同时提供了多时间点的函数回调机制。这些特点为我们的修复工作提供了机会。通过学习分析应用软件动态更新过程中可能出现的各种错误状态类型。我们从线程死锁这个常见的简单错误着手,研究这类错误典型代码的特点,并结合POLUS动态更新框架的功能特点,尝试各种使用动态更新补丁进行错误修复的可能性,寻求最佳解决方案,并通过这个典型案例总结经验,归纳出可行的修复方法。接着,从CERT等关注于软件可用性和安全性问题的专业网站上的大量真实案例中发掘适合展开修复工作的实际案例。随后,按照先前总结的修复方法,我们又针对内存管理错误案例和结构化数据错误案例进行了大量案例分析和代码研究,提出了具有启示性的修复方案。修复方案的具体实现工作主要都是通过在POLUS动态补丁中增加相关的修复函数和接口的手段实现。经过努力,我们基本上达到了预期的目标。各个修复案例相关的测试表明,我们的针对相关的错误状态提出的修复方案是可行的,有效的,并且对部分案例的测试还表明对应用软件的影响极小。