https://bugs.kde.org/show_bug.cgi?id=368126
Alwyn changed:
What|Removed |Added
CC||alwyn+...@kik.pw
--- Comment #5 from Alwyn ---
I am
https://bugs.kde.org/show_bug.cgi?id=424788
Alwyn <906497...@qq.com> changed:
What|Removed |Added
Resolution|--- |FIXED
Status|RE
info
==3588== Command: ./sensor_daemon
==3588==
Connection established with kernel.
resource->hdr_mode:0 HDR_PIPELINE_ADV:2
resource->hdr_expo_num:1, HDR_2X:2 night_mode:0
---load mliso_adj_param---
!!!
[/home2/alwyn/sdk2.6_all_trunk/src/sysapps/vendor/packages/img_mw/mw/a
https://bugs.kde.org/show_bug.cgi?id=424788
--- Comment #6 from Alwyn <906497...@qq.com> ---
(In reply to Tom Hughes from comment #5)
> I think what's happening is that depending on the CPU architecture the IFUNC
> is sometimes resolving the memcpy call to the memmove implementa
https://bugs.kde.org/show_bug.cgi?id=424788
--- Comment #3 from Alwyn <906497...@qq.com> ---
(In reply to Tom Hughes from comment #2)
> Hmm no it doesn't, which is very odd.
When I used memcheck for the first time, I tested this code, and the result was
the expected result I sub
Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==6356== Command: ./test
==6356==
==6356== Invalid write of size 4
==6356==at 0x1091AB: test (in /home/alwyn/文档/test)
==6356==by 0x109201: main (in /home/alwyn/文档/test)
==6356== Address 0x4a51068 is 0 bytes after a block of si