我正在使用gcov为我们的项目获取代码覆盖率,但它经常报告普通函数调用的50%条件覆盖率。 如果函数接受任何参数或返回任何数据,它没有任何区别。 我正在使用gcovr和Cobertura和Jenkins,但是一个简单的gcov文件会给出相同的结果。 下面附有实际测试的代码以及存根函数,所有这些都是gcov格式。 有什么想法为什么gcov威胁这些函数调用分支?

        -:  146:/*****************************************************************************/
function _Z12mw_log_clearv called 2 returned 100% blocks executed 100%
        2:  147:void mw_log_clear( void )
        2:  147-block  0
        -:  148:{
        2:  149:    uint8_t i = 0;
        2:  150:    uint8_t clear_tuple[EE_PAGE_SIZE] = { 0xff };
        -:  151:    
       66:  152:    for (i = 0; i < (int16_t)EE_PAGE_SIZE; i++)
        2:  152-block  0
       64:  152-block  1
       66:  152-block  2
branch  0 taken 97%
branch  1 taken 3% (fallthrough)
        -:  153:    {
       64:  154:        clear_tuple[i] = 0xff;
        -:  155:    }
        -:  156:    
        -:  157:    /* Write pending data */
        2:  158:    mw_eeprom_write_blocking();
        2:  158-block  0
call    0 returned 100%
branch  1 taken 100% (fallthrough)    <---- This is a plain function call, not a branch
branch  2 taken 0% (throw)            <---- This is a plain function call, not a branch
        -:  159:    
       26:  160:    for (i = 0; i < (RESERVED_PAGES_PER_PAREMETER_SET - POPULATED_PAGES_PER_PAREMETER_SET); i++)
        2:  160-block  0
       24:  160-block  1
       26:  160-block  2
branch  0 taken 96%
branch  1 taken 4% (fallthrough)
        -:  161:    {
       25:  162:        if (status_ok != mw_eeprom_write(LOG_TUPLE_START_ADDRESS + i * EE_PAGE_SIZE, clear_tuple, sizeof(clear_tuple)))
       25:  162-block  0
call    0 returned 100%
branch  1 taken 100% (fallthrough)    <---- This is a plain function call, not a branch
branch  2 taken 0% (throw)            <---- This is a plain function call, not a branch
       25:  162-block  1
branch  3 taken 4% (fallthrough)
branch  4 taken 96%
        -:  163:        {
        1:  164:            mw_error_handler_add(mw_error_eeprom_busy);
        1:  164-block  0
call    0 returned 100%
branch  1 taken 100% (fallthrough)    <---- This is a plain function call, not a branch
branch  2 taken 0% (throw)            <---- This is a plain function call, not a branch
        1:  165:            break;
        1:  165-block  0
        -:  166:        }
        -:  167:        
       24:  168:        mw_eeprom_write_blocking();
       24:  168-block  0
call    0 returned 100%
branch  1 taken 100% (fallthrough)   <---- This is a plain function call, not a branch
branch  2 taken 0% (throw)           <---- This is a plain function call, not a branch
        -:  169:    }
        2:  170:}
        2:  170-block  0
        -:  171:
        -:  172:/*****************************************************************************/

/ ******************* ************ /

void mw_eeprom_write_blocking(void)
{
    stub_data.eeprom_write_blocking_calls++;
}

/ ******************* ************ /

void mw_error_handler_add(mw_error_code_t error_code)
{
    EXPECT_EQ(error_code, stub_data.expected_error_code);
    stub_data.registered_error_code = error_code;
}

/ ******************* ************ /

status_t mw_eeprom_write(
        const uint32_t eeprom_start_index,
        void *const source_start_address,
        const uint32_t length)
{
    stub_data.eeprom_write_start_index = eeprom_start_index;
    stub_data.eeprom_write_length = length;
    stub_data.eeprom_write_called = true;

    EXPECT_NE(NULL, (uint32_t)source_start_address);
    EXPECT_NE(0, length);
    EXPECT_LE(eeprom_start_index + length, EEPROM_SIZE);

    if (status_ok == stub_data.eeprom_write_status)
        memcpy(&stub_data.eeprom[eeprom_start_index], source_start_address, length);

    return stub_data.eeprom_write_status;
}

#1楼 票数:3 已采纳

解决了!

在这个帖子中找到答案: 为什么gcc 4.1 + gcov报告100%分支覆盖率和更新(4.4,4.6,4.8)报告50%用于“p =新类;” 线?

似乎gcov对这些函数调用的某些“不可见”异常处理代码做出了反应,因此在g ++中添加“-fno-exceptions”会使所有这些缺失的分支消失。

  ask by MrDanne translate from so

未解决问题?本站智能推荐:

2回复

使用Cobertura输出Gcov的颜色代码

我在Jenkins上设置了gcov代码覆盖工具。 这工作正常,但我在处理输出颜色代码时遇到了麻烦。 每条线的“命中数”是核心,但是当其他线为红色时,某些线是绿色的,我不知道为什么。 示例: 请注意,setYear方法全部为绿色,并且调用了13次(ctor + setDateAAMM
1回复

是否有将EmmaXML报告转换为CoberturaXML格式的工具?

我使用的代码覆盖率工具只能生成Emma XML报告,而我需要的是Cobertura或gcov格式。 是否已经存在一些进行转换的工具? 如果没有,我担心我必须自己做。
2回复

为什么gcc4.1+gcov报告100%的分支覆盖率,而较新的(4.4,4.6,4.8)报告“p=newclass”为50%;线?

当 gcc 4.1(使用 gcov)下一行时: p = 新类; 被报告为 100% 分支覆盖率 <-- 这对我来说没问题。 为什么使用 gcc 4.4 和更高版本的同一行报告为: [+ -] p = 新类; (50% 分支覆盖率)... <-- 这是覆盖 100% 的问题!!! 我
1回复

带有Cobertura插件的Play分支覆盖!构架

我正在使用Play! 具有Cobertura模块的 框架以获取代码覆盖率。 这可以正常工作,但不幸的是,该模块似乎也没有(显而易见的)选项来制作分支覆盖率报告。 如何在Cobertura模块中启用分支覆盖? 换句话说,您如何在Play应用程序中测试分支覆盖率?
3回复

有没有一种方法可以避免在“elsif”分支中多次调用函数?

我有一个返回nil或非nil值的函数,并且在以下if - else子句中使用它: 我觉得上面的代码块有点浪费,因为它两次调用了该函数,并且可能只保存一次结果,如果分支的计算结果为非nil ,则可以在以下子句中使用它。 有没有办法重写它,以便我只调用一次函数?
1回复

如何为模板函数调用解释gcov结果

问题1:如何解密函数名称,例如_ZN21CircularBufferManager4readIlEEmPT_m? 我猜在那些长函数名(即l,t,h,d)中,“读取”之后的第二个字符必须与类型有关。 我使用unsigned char,unsigned short,signed long,dou
1回复

sed有多行节的条件分支

我第一次尝试用sed进行多行替换。 我在那里找到了两个很好的指针( 一般的多行帮助和两个字符串之间的多行 )。 使用它作为启动器,我有以下命令: 我的输入文件具有以下内容: 不幸的是,对于所有部分,我都得到“ CHANGE_A”。 据我了解,这意味着sed始终认为第一个替换项什么也
1回复

OSB阶段中具有Assign的条件分支

我在代理服务中有一个条件分支,但是如果值是'old',则需要调用一个条件分支,否则,流程将转到默认值。 事实是该值必须是可编辑的,这意味着该值不会在服务请求中发送,可以在OSB控制台中进行更改,我试图在条件分支和变量之前使用一个阶段,但这可以从Cond访问。 分支(超出范围) 我不知道