cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

german
Staff
Staff

Re: Memory corruption in latest crimson driver 15.302?

Jump to solution

1. Freqs array reallocation in the code looks broken. The code below:

freqs[fidx].hz = sig.hz;

freqs[fidx++].ts = ts;

if (fidx >= maxfreqs) {

maxfreqs += 16;

freqs = realloc(freqs, maxfreqs);

}

Should be something

if (fidx == (maxfreqs-1)) {

maxfreqs += 16;

freqs = realloc(freqs, maxfreqs * sizeof(freq_t));

}

freqs[fidx].hz = sig.hz;

freqs[fidx++].ts = ts;

2. You call run_fft() with pass=8 and that causes access to a destroyed cl_event ndr on the pass=7.

You destroyed ndr (pass=7)

if (pass == MAXPASS - 1) {

    if ((err = waitForEventAndRelease(&ndr)) != SUCCESS)

you have access to a destroyed object and corrupt memory. (pass=8)

if (pass && (err = waitForEventAndRelease(&ndr)) != SUCCESS)

nibal
Challenger

Re: Memory corruption in latest crimson driver 15.302?

Jump to solution

Hi,

Oops, sorry about that. These 2 were artifacts of the test file, the additional invalid reads. Should have checked it more carefully before shipping it out, but it was quite complex. However, after fixing them, leaves the original memory corruption. I imagine you must have recreated it by now

Thank you for your feedback,

Nikos

0 Likes
gstoner
Staff
Staff

Re: Memory corruption in latest crimson driver 15.302?

Jump to solution

When the team fixed these two issues. The corruption was no longer there

Only crashed with the two issues

Greg

Sent from Outlook Mobile<https://aka.ms/qtex0l>

0 Likes
nibal
Challenger

Re: Memory corruption in latest crimson driver 15.302?

Jump to solution

These were artifacts of the test file as noted initially. I'm still getting the original problem:

==00:00:00:49.169 4191== Invalid write of size 8^M
==00:00:00:49.170 4191== at 0x4C2F0F3: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1017)^M
==00:00:00:49.170 4191== by 0x68E8154: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x68EA99A: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x68ED911: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x68F7F98: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x68F8667: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x68F8838: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x685BCFB: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x688382C: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x6883BD6: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x6824DAC: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x682512C: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x67C315E: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x683315B: ??? (in /usr/lib/libamdocl64.so)^M
==00:00:00:49.170 4191== by 0x4E3F181: start_thread (pthread_create.c:312)^M
==00:00:00:49.170 4191== by 0x565C47C: clone (clone.S:111)^M
==00:00:00:49.170 4191== Address 0x7fbf95aaf000 is not stack'd, malloc'd or (recently) free'd^M
==00:00:00:49.170 4191== ^M
{^M

Is this a false positive? Do you not see it in your valgrind?

BR,

Nikos

0 Likes
nibal
Challenger

Re: Memory corruption in latest crimson driver 15.302?

Jump to solution

Hi,

After a week of extensive testing of the test program, without any problems, i can confirm that the valgrind report is a false positive.

Whatever other memory problems I have in my original program are due to my code.

Thank you,

Nikos

0 Likes