首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    GreatSQL的多层SP中Cursor的m_max_cursor_index相关BUG分析

    一、问题发现 在一次开发中在sp中使用多层cursor的时候想知道每层的m_max_cursor_index值分别是多少,以用来做后续开发。 于是做了以下的试验,但是发现第一个level=2那层的m_max_cursor_index的值有点问题。 注:本次使用的GreatSQL 8.0.32-25 SQL语句示例: greatsql> CREATE TABLE t1 (a INT, b VARCHAR(10)); 以下注释里面是该层sp_pcontext的参数值。 DELIMITER $$ CREATE PROCEDURE processnames() -- level=0,m_max_cursor_index=1+8+1 BEGIN DECLARE nameCursor0 CURSOR FOR SELECT * FROM t1; -- level=1,m_cursor_offset=0,m_max_cursor_index=1+8+1 begin DECLARE nameCursor1 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1+8 ☆问题点 begin DECLARE nameCursor2 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=1 DECLARE nameCursor3 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=2 DECLARE nameCursor4 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=3 DECLARE nameCursor5 CURSOR FOR SELECT * FROM t1; -- level=3,m_cursor_offset=2,m_max_cursor_index=4 end; end; begin DECLARE nameCursor6 CURSOR FOR SELECT * FROM t1; -- level=2,m_cursor_offset=1,m_max_cursor_index=1 end; END $$ DELIMITER ; 首先查看上面的sp的code,可以发现nameCursor6和nameCursor1属于同一层,因此他们的offset值一样。 greatsql> show procedure code processnames; +-----+---------------------------------------+ | Pos | Instruction | +-----+---------------------------------------+ | 0 | cpush nameCursor0@0: SELECT * FROM t1 | | 1 | cpush nameCursor1@1: SELECT * FROM t1 | | 2 | cpush nameCursor2@2: SELECT * FROM t1 | | 3 | cpush nameCursor3@3: SELECT * FROM t1 | | 4 | cpush nameCursor4@4: SELECT * FROM t1 | | 5 | cpush nameCursor5@5: SELECT * FROM t1 | | 6 | cpop 4 | | 7 | cpop 1 | | 8 | cpush nameCursor6@1: SELECT * FROM t1 | | 9 | cpop 1 | | 10 | cpop 1 | +-----+---------------------------------------+ 11 rows in set (6.02 sec) 然后通过debug查看每层 sp_pcontext 的参数值(相关参数值已经在上面标识出),发现第一个level=2的sp_pcontext的m_max_cursor_index值多了很多,预期值应

    01

    窗口分割

    我们在使用OutLook或者NetAnt等工具的时候,一般都会被其复杂的界面所吸引,在这些界面中窗口被分割为若干的区域,真正做到了窗口的任意分割。 那么我们自己如何创建类似的界面,也实现窗口的任意的分割呢?要解决这个问题,在Visual C++6.0编程中就需要使用到MFC提供的CSplitterWnd类。CSplitterWnd看上去像是一种特殊的框架窗口,每个窗口都被相同的或者不同的视图所填充。当窗口被切分后用户可以使用鼠标移动切分条来调整窗口的相对尺寸。虽然VC6.0支持从AppWizard中创建分割窗口,但是自动加入的分割条总是不能让我们满意,因此我们还是通过手工增加代码来熟悉这个类。本实例采用多模板模式,即实现了窗口的任意分割,又介绍了各个视图如何相互通信。程序编译运行后的界面效果如图一所示:

    02

    Minfilter过滤框架

    与传统的Sfilter过滤驱动相比,有这样几个优势 1. Minfilter加载顺序更易控制,Sfilter加载是随意的,也就是说它在IO设备栈上的顺序是根据其创建的顺序决定的,越晚创建的,越排在设备栈的顶部,而Minfilter根据它的一个全局变量——altitude规定了它在设备栈上的顺序 2. 具有可卸载能力,一般的hook或者过滤框架在卸载时可能仍然有程序在访问它们的代码,所以如果在有程序访问其代码,而它又被卸载时容易导致蓝屏,这样就不具备可卸载能力。而Minfilter则不会导致蓝屏 3. Minfilter是通过注册回调函数到Minfilter管理器中,由Minfilter管理器来负责调度这些函数,不直接与IO管理器接触,同时我们只需要注册我们感兴趣的回调函数,而不像Sfilter那样,需要提供一个统一的处理函数。所以相对来说更简单 4. 兼容性更好,由IO管理器下发的IRP 请求既可以交给Sfilter框架处理,也可以交给Minfilter处理,也可以给下层的设备驱动处理。 5. 名字处理处理更加容易,相对与Sfilter中需要另外顶一个一个NAME_CONTROL结构,还需要注意长短名来说,Minfilter更加简单,只需要一个简单的函数就可以获取文件的卷设备名称,文件全名,流名等信息

    03

    用单步异常检测OllyDbg的巧妙方法

    SEH大概算得上是WINDOWS下公开的秘密了,什么?您还不知道?没关系,下面我来简单地介绍一下。SEH即结构化异常处理(Structured Exception Handling),简单地说就是当程序出现错误时,系统把当前的一些信息压入堆栈,然后转入我们设置好的异常处理程序中执行,在异常处理程序中我们可以终止程序或者修复异常后继续执行。异常处理处理分两种,顶层异常处理和线程异常处理,下面我们要用到的是线程异常处理。具体做法是,每个线程的FS:[0]处都是一个指向包含异常处理程序的结构的指针,这个结构又可以指向下一个结构,从而形成一个异常处理程序链。当发生异常时,系统就沿着这条链执行下去,直到异常被处理为止。我们可以使FS:[0]指向我们自己写的异常处理程序,从而自己处理异常。这里只是关于异常处理的简单介绍,具体内容请参考看雪学院的《加密与解密》及相关的windows编程书籍。 我们都知道用调试器(下面的介绍都以当前流行的调试器OllyDbg为例)可以设置断点,那么当设置断点时调试器究竟是怎样工作的呢?这要分几种情况了,一种是代码断点,即Cracker在某行代码上下断点,这时调试器自动把这行代码的首字节改为CC(即INT3中断,这个修改在OD中不会显示)这样每当程序运行到这里都会产生中断,而调试器可以接管这个中断,从而实现对程序的控制;另一种是内存断点,即当程序对某处内存有操作(读或写)时产生中断,这是直接利用CPU的调试寄存器DRx来完成的;还有一种不太像中断的“中断”,即单步中断,也就是说当你在调试器中选择“步过”某条指令时,程序自动在下一条语句停下来,这其实也属于一种中断,而且可以说是最常用的一种形式了,当我们需要对某段语句详细分析,想找出程序的执行流程和注册算法时必须要进行这一步。是80386以上的INTEL CPU中EFLAGS寄存器,其中的TF标志位表示单步中断。当TF为1时,CPU执行完一条指令后会产生单步异常,进入异常处理程序后TF自动置0。调试器通过处理这个单步异常实现对程序的中断控制。持续地把TF置1,程序就可以每执行一句中断一次,从而实现调试器的单步跟踪功能。 讲到这里,不知聪明的您看出什么问题没有:如果我们的程序本身就含有对单步异常的处理程序会怎么样呢?呵呵,据笔者的实验是,OD会不理睬我们程序自己的单步异常处理程序而自顾自地把异常处理接管了。这其实就给了我们一种很巧妙的方法,我们可以自己把TF置1,然后把注册算法中十分关键的运算放在我们程序自己的单步异常处理程序中。这样当程序在正常条件下执行时,一旦产生单步异常就会转到我们自己写好的异常处理中继续进行而不会受到影响,如果程序被调试,而Cracker选择了按F8步过这段程序,那么这时产生的单步异常会被调试器忽略,这样那些关键的代码就得不到执行,从而产生令人十分迷惑的结果。 好了,说了这么多,下面看一个实际的例子:(MASM32 8.2下编译通过)

    03

    扫码

    添加站长 进交流群

    领取专属 10元无门槛券

    手把手带您无忧上云

    扫码加入开发者社群

    相关资讯

    热门标签

    活动推荐

      运营活动

      活动名称
      广告关闭
      领券