Crash on Qt application related to the date

Match0um

Hi there,

We are facing a big issue on our program.
Whatever the revision, they all crash when I call a specified external dll.

I do not know yet the reason, but the countermeasure is to go backward in the past, setting up the computer date before August, 15th... No more issue then.

I am stacked with the following message from the debug, if someone can help on that purpose:
python theDumper.fetchStack ==> WHAT IS THAT ?

Thanks !

Complete trace :

~"\nThread "
~"1 received signal SIGSEGV, Segmentation fault.\n"
~"0x000000006fb415c0 in ?? () from C:\Users\XXUser\Desktop\build-Desktop_Qt_5_12_3_MinGW_64_bit-Release\release\ApiUSCable.dll\n"
*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",frame={addr="0x000000006fb415c0",func="??",args=[],from="C:\Users\XXUser\Desktop\build-Desktop_Qt_5_12_3_MinGW_64_bit-Release\release\ApiUSCable.dll"},thread-id="1",stopped-threads="all"
dNOTE: INFERIOR SPONTANEOUS STOP
Stopped.
dState changed from InferiorRunOk(8) to InferiorStopOk(11)
<171importPlainDumpers off
dHANDLING SIGNAL SIGSEGV
Stopped: Segmentation fault (Signal SIGSEGV).

172-thread-info
&"importPlainDumpers off\n"
~"155 printers disabled\n"
~"0 of 155 printers enabled\n"
~"None\n"
171^done

172^done,threads=[{id="1",target-id="Thread 15144.0x46bc",frame={level="0",addr="0x000000006fb415c0",func="??",args=[],from="C:\Users\XXUser\Desktop\build-Desktop_Qt_5_12_3_MinGW_64_bit-Release\release\ApiUSCable.dll"},state="stopped"},{id="2",target-id="Thread 15144.0x1b84",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="3",target-id="Thread 15144.0x3ce4",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="4",target-id="Thread 15144.0x4da4",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="5",target-id="Thread 15144.0x4c9c",frame={level="0",addr="0x00007fff4691d8e4",func="ntdll!ZwWaitForMultipleObjects",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="6",target-id="Thread 15144.0x3cac",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="7",target-id="Thread 15144.0x2d28",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="8",target-id="Thread 15144.0x3a20",frame={level="0",addr="0x00007fff46920724",func="ntdll!ZwWaitForWorkViaWorkerFactory",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="9",target-id="Thread 15144.0xc40",frame={level="0",addr="0x00007fff4691d8e4",func="ntdll!ZwWaitForMultipleObjects",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="10",target-id="Thread 15144.0x9ec",frame={level="0",addr="0x00007fff4691d8e4",func="ntdll!ZwWaitForMultipleObjects",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="11",target-id="Thread 15144.0x23dc",frame={level="0",addr="0x00007fff4691ce14",func="ntdll!ZwWaitForSingleObject",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="12",target-id="Thread 15144.0x2478",frame={level="0",addr="0x00007fff4691ceb4",func="ntdll!ZwRemoveIoCompletion",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"},{id="13",target-id="Thread 15144.0x12f8",frame={level="0",addr="0x00007fff4691ce14",func="ntdll!ZwWaitForSingleObject",args=[],from="C:\windows\SYSTEM32\ntdll.dll"},state="stopped"}],current-thread-id="1"
<173python theDumper.fetchStack({"limit":20,"nativemixed":0,"token":173})

&"python theDumper.fetchStack({"limit":20,"nativemixed":0,"token":173})\n"
~"result={token="0",stack={frames=[frame={level="0",address="0x6fb415c0",function="??",file="",line="0",module="",language="c"}frame={level="1",address="0x2",function="??",file="",line="0",module="",language="c"}]}}\n"
173^done
<174set disassembly-flavor att
<175-interpreter-exec console "disassemble /rs 0x6fb415c0"
<176-stack-select-frame 0
<177python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["local","inspect","watch","return"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":0,"token":177,"typeformats":{},"watchers":[]})

&"set disassembly-flavor att\n"
174^done

&"No function contains specified address.\n"
175^error,msg="No function contains specified address."
<178-interpreter-exec console "disassemble /rs 0x6fb415ac,0x6fb41624"

176^done

&"python theDumper.fetchVariables({"autoderef":1,"context":"","displaystringlimit":"100","dyntype":1,"expanded":["local","inspect","watch","return"],"fancy":1,"formats":{},"nativemixed":0,"partialvar":"","passexceptions":0,"qobjectnames":1,"resultvarname":"","stringcutoff":"10000","timestamps":0,"token":177,"typeformats":{},"watchers":[]})\n"
~"result={token="0",data=[],typeinfo=[],partial="0",counts={},timings=[]}\n"
177^done
<Rebuild Watchmodel 3 @ 15:00:53.171 [736277ms] >
Finished retrieving data.

~"Dump of assembler code from 0x6fb415ac to 0x6fb41624:\n"
~" 0x000000006fb415ac:\t00 00\tadd %al,(%rax)\n"
~" 0x000000006fb415ae:\t00 00\tadd %al,(%rax)\n"
~" 0x000000006fb415b0:\t48 c7 44 24 08 01 00 00 00\tmovq $0x1,0x8(%rsp)\n"
~" 0x000000006fb415b9:\tb8 01 00 00 00\tmov $0x1,%eax\n"
~" 0x000000006fb415be:\t66 90\txchg %ax,%ax\n"
~"=> 0x000000006fb415c0:\t48 89 44 c4 08\tmov %rax,0x8(%rsp,%rax,8)\n"
~" 0x000000006fb415c5:\t48 8b 44 24 08\tmov 0x8(%rsp),%rax\n"
~" 0x000000006fb415ca:\t48 83 c0 01\tadd $0x1,%rax\n"
~" 0x000000006fb415ce:\t48 85 c0\ttest %rax,%rax\n"
~" 0x000000006fb415d1:\t48 89 44 24 08\tmov %rax,0x8(%rsp)\n"
~" 0x000000006fb415d6:\t75 e8\tjne 0x6fb415c0\n"
~" 0x000000006fb415d8:\t48 83 c4 18\tadd $0x18,%rsp\n"
~" 0x000000006fb415dc:\tc3\tretq \n"
~" 0x000000006fb415dd:\t90\tnop\n"
~" 0x000000006fb415de:\t66 90\txchg %ax,%ax\n"
~" 0x000000006fb415e0 <_ZN10ApiUSCableC2Es+0>:\t56\tpush %rsi\n"
~" 0x000000006fb415e1 <_ZN10ApiUSCableC2Es+1>:\t53\tpush %rbx\n"
~" 0x000000006fb415e2 <_ZN10ApiUSCableC2Es+2>:\t48 83 ec 28\tsub $0x28,%rsp\n"
~" 0x000000006fb415e6 <_ZN10ApiUSCableC2Es+6>:\t48 89 cb\tmov %rcx,%rbx\n"
~" 0x000000006fb415e9 <_ZN10ApiUSCableC2Es+9>:\t89 d6\tmov %edx,%esi\n"
~" 0x000000006fb415eb <_ZN10ApiUSCableC2Es+11>:\t31 d2\txor %edx,%edx\n"
~" 0x000000006fb415ed <_ZN10ApiUSCableC2Es+13>:\tff 15 7d 31 01 00\tcallq *0x1317d(%rip) # 0x6fb54770\n"
~" 0x000000006fb415f3 <_ZN10ApiUSCableC2Es+19>:\t48 8b 05 d6 c2 00 00\tmov 0xc2d6(%rip),%rax # 0x6fb4d8d0\n"
~" 0x000000006fb415fa <_ZN10ApiUSCableC2Es+26>:\t48 8d 4b 10\tlea 0x10(%rbx),%rcx\n"
~" 0x000000006fb415fe <_ZN10ApiUSCableC2Es+30>:\t31 d2\txor %edx,%edx\n"
~" 0x000000006fb41600 <_ZN10ApiUSCableC2Es+32>:\t48 83 c0 10\tadd $0x10,%rax\n"
~" 0x000000006fb41604 <_ZN10ApiUSCableC2Es+36>:\t48 89 03\tmov %rax,(%rbx)\n"
~" 0x000000006fb41607 <_ZN10ApiUSCableC2Es+39>:\te8 14 9b 00 00\tcallq 0x6fb4b120 <_ZN10ApiUSCable11qt_metacallEN11QMetaObject4CallEiPPv+25440>\n"
~" 0x000000006fb4160c <_ZN10ApiUSCableC2Es+44>:\tc6 43 20 00\tmovb $0x0,0x20(%rbx)\n"
~" 0x000000006fb41610 <_ZN10ApiUSCableC2Es+48>:\tf2 0f 10 05 b0 bb 00 00\tmovsd 0xbbb0(%rip),%xmm0 # 0x6fb4d1c8\n"
~" 0x000000006fb41618 <_ZN10ApiUSCableC2Es+56>:\t66 89 73 18\tmov %si,0x18(%rbx)\n"
~" 0x000000006fb4161c <_ZN10ApiUSCableC2Es+60>:\tf2 0f 11 43 40\tmovsd %xmm0,0x40(%rbx)\n"
~" 0x000000006fb41621 <_ZN10ApiUSCableC2Es+65>:\tc7 43 4c ff ff ff ff\tmovl $0xffffffff,0x4c(%rbx)\n"
~"End of assembler dump.\n"
178^done

SGaist

Hi,

Since it's an external DLL, and you seem to have a reproducible case way to trigger it, you should create a minimal test case triggering it and the contact their authors about that.

Match0um

Hi,

Thanks for support.
I am the author of the external dll. And there is nothing in it related to current date :(

So I try to go deeper in the analysis of the trace to understand what's going on, but this message is quite obscure for me.

JKSH

@Match0um said in Crash on Qt application related to the date:

I am the author of the external dll. And there is nothing in it related to current date :(

Are you able to create a Debug build of your DLL, and also trigger the crash from a C++ application? A C++ stack trace might show you more details of what functions were called leading up to the crash.

kshegunov

From a glance you seem to be emitting a signal from an already deleted object here:

callq 0x6fb4b120 <_ZN10ApiUSCable11qt_metacallEN11QMetaObject4CallEiPPv+25440

Best advice - debug your library and fix the bug.

Match0um

OK thanks for your help !
I tried to debug my DLL.

It seems to be wrong on my pointer (surprinsigly..)

Is anybody able to find what's wrong ?
It was with malloc/free. I tried with new/delete. But as soon as I enter this function, I hit a HEAP when I try to delete my pointer.

void ApiUSCable::coderAscan_8b(uint16_t *buff, int sizeBuffer)
{
    if(!_init)
        return;

    //uint8_t *buf_8b = (uint8_t*)malloc(sizeBuffer*2);
    uint8_t *buf_8b;
    buf_8b = new uint8_t [sizeBuffer*2];

    uint8_t cmd[2]  = {0x00, CODEUR_ASCAN_8bits};

    //Lecture sur 8 bits
    uint8_t ret=1;

    ret = uscable_parallel_out(_channel, cmd, sizeof(cmd), TIMEOUT_WRITE);
    if (ret != 0) {qde << "[coderAscan_8b] parallel out " << ret ; delete buf_8b; return; } 

    ret = uscable_parallel_in(_channel, buf_8b, sizeof(buf_8b), TIMEOUT_WRITE);
    if (ret != 0) {qde << "[coderAscan_8b] parallel in " << ret ; delete buf_8b; return; } 

    for(int i=0 ;i< sizeBuffer*2 ;i+=2)
        buff[i-i/2] = (uint16_t)(buf_8b[i]) + ((uint16_t)buf_8b[i+1]<<8);

    delete buf_8b;
    return;

JonB

@Match0um
I don't know whether this is your issue, but if you new an array (new uint8_t [sizeBuffer*2]) you are supposed to delete[] it (delete[] buf_8b).

Otherwise check whatever your for loop is supposed to do it does not go out-of-bounds on either where it reads from or where it writes to in particular.

JKSH

@Match0um said in Crash on Qt application related to the date:

It was with malloc/free. I tried with new/delete. But as soon as I enter this function, I hit a HEAP when I try to delete my pointer.

Don't use malloc or new[] for the array. Use a std::vector or a QVector instead -- then you don't have to worry about freeing the memory.

mchinand

@Match0um said in Crash on Qt application related to the date:

for(int i=0 ;i< sizeBuffer*2 ;i+=2)
buff[i-i/2] = (uint16_t)(buf_8b[i]) + ((uint16_t)buf_8b[i+1]<<8);

What's the size of buff that you are passing in? If it's sizeBuffer, I think you're going out-of-bounds here. Do you want the index to just be buff[i/2]?

kshegunov

@mchinand said in Crash on Qt application related to the date:

What's the size of buff that you are passing in? If it's sizeBuffer, I think you're going out-of-bounds here. Do you want the index to just be buff[i/2]?

And in addition what's with the byte-by-byte shifts and such? What's wrong with passing the buffer directly to the API?

@Match0um said in Crash on Qt application related to the date:

ret = uscable_parallel_in(_channel, buf_8b, sizeof(buf_8b), TIMEOUT_WRITE);

And as a second note:

sizeof(buf_8b) == sizeof(void *)

which is not what you want, I'm pretty sure.

Match0um

@Match0um said in Crash on Qt application related to the date:

ret = uscable_parallel_in(_channel, buf_8b, sizeof(buf_8b), TIMEOUT_WRITE);

The function uscable_parallel_in wait for a uint8_t * pdata as second argument.

So I think I can not skip pointer :'(

buff is created depending on sizeBuffer

buff = (unsigned short *)malloc(sizeBuffer* sizeof(unsigned short));

@mchinand why do you think I am out of bounds at any moment ? I double checked my for and can't find the trouble.

Aim of this code is to convert 2 arrays of 8 bit (buf_8b) received from an external device into one array of 16b

As a reminder for the investigation, everything works like a charm when I back the clock of the computer ...

mchinand

No, that looks OK. I was expecting the index to be i/2 and didn't notice that your i - i/2 simplifies to i/2.

DerReisende

This post is deleted!

kshegunov

I'm going to repeat myself. What does this output?

qDebug() << sizeBuffer*2 << sizeof(buf_8b);

Match0um

@kshegunov
sizeBuffer*2= 0
sizeof(buf_8b)= 8

JonB

@Match0um said in Crash on Qt application related to the date:

sizeBuffer*2= 0

So if the sizeBuffer parameter is passed in as 0 what do you expect?! :) Doesn't that worry you? It would have been the first thing I would have checked....

Match0um

@JonB
Maybe I am not as good as you are then ;)

I would have been worried if sizeof(buf_8b)=0.

Here I guess I do not even enter my for loop.

JonB

@Match0um

void ApiUSCable::coderAscan_8b(uint16_t *buff, int sizeBuffer)

Your method takes a pointer to a buffer and the size of that buffer, to write into for the caller. If the caller passes 0 as the size of the buffer it's not going to get much back from this method :)

KroMignon

@Match0um said in Crash on Qt application related to the date:

Maybe I am not as good as you are then ;)
I would have been worried if sizeof(buf_8b)=0.
Here I guess I do not even enter my for loop.

The problem is not buf_8b = new uint8_t [sizeBuffer*2] with sizeBuffer = 0 , this should work.
But dereferencing a pointer returned as a request for zero size is undefined. So delete[] buf_8b may crash or corrupt your application memory!

I would recommend you to change your code as follow:

void ApiUSCable::coderAscan_8b(uint16_t *buff, int sizeBuffer)
{
    if(!_init || sizeBuffer <= 0 || !buff)
        return;
    ....
}

JonB

@KroMignon said in Crash on Qt application related to the date:

The problem is not buf_8b = new uint8_t [sizeBuffer*2] with sizeBuffer = 0 , this should work.
But dereferencing a pointer returned as a request for zero size is undefined. So delete[] buf_8b may crash or corrupt your application memory!

[My bold.] I disagree with your "may crash or corrupt your application memory". new [0] will return a pointer to an allocated area ready to hold 0 bytes. It is true that the user cannot then access anything at that address. However delete[] is not a deference, it frees the memory allocated, and in fact the code should leak if this is not performed. Reference: C++ new int[0] -- will it allocate memory?, and the answers there.