Crash on Qt application related to the date

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.

kshegunov

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

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

Now, could you give a reasonable way this should work?

// Allocated to contain 0 elements
uint8_t *buf_8b;
buf_8b = new uint8_t [sizeBuffer*2]; 

// ...

// Buffer is size 0, but the API's told it has a size of sizeof(buf_8b) == sizeof(void *) == 8
ret = uscable_parallel_in(_channel, buf_8b, sizeof(buf_8b), TIMEOUT_WRITE);

Now, the million dollars question is: what happens when uscable_parallel_in starts writing beyond the boundaries of the passed buffer, which is unsurprisingly at each and every call?

Match0um

Hi all,

Thanks again (really) for your time and your ideas.
@kshegunov unfortunately, I don't have and don't need a million dollars so I won't answer your quetion :D
BUT you pointed out a nice error.
This is what my dll looks like now, and it works perfectly !... in debug mode.
But I still have my date related issue in release, which does not happen in debug, and which is perhaps not even related to this dll...

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

    if(!_init || sizeBuffer<=0)
        return;

    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, sizeBuffer*2, TIMEOUT_WRITE);
    if (ret != 0) {qde << "[coderAscan_8b] parallel in " << ret ; delete buf_8b; return; } 

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

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

    delete[] buf_8b;
    return;
}

KroMignon

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

But I still have my date related issue in release, which does not happen in debug, and which is perhaps not even related to this dll...

It looks like you are using MSVC, you should know that MSVC always initialize class members per default with 0, but this is not the case in release.
I would suggest you to verify that you always initialize all variables/classes members before you are using them!

Match0um

@KroMignon
I develop on Windows with mingw.

It's all about my dll... debug version works fine.
Release version crash on QtCreator with today date, runs well with june date.

And everything run fine with the .exe -_-

JonB

@Match0um
You have mentioned about "date" several times. Am I the only one who cannot see anything about a date in your code? Please explain/clarify.

kshegunov

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

It's all about my dll... debug version works fine.
Release version crash on QtCreator

Build release with debug info, run it in Creator and get a stack trace from the crash.

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

Am I the only one who cannot see anything about a date in your code?

Not at all, I just've been ignoring it, since nothing points to anything time related, not the trace, code or explanations.