https://bugs.kde.org/show_bug.cgi?id=376956
--- Comment #4 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- Strange: effectively, the 2 traces are showing that the same syscall is done. Unclear what is happening at this stage : it looks like the address 0x0 is considered by valgrind as accessible and defined in the Pascal application. Can you do the following test: Use vgdb to connect GDB to your program running under Valgrind. Put a breakpoint just before the failing access syscall, and then in GDB, check the VA bits using: monitor get_vbits 0x0 10 If the 10 bytes at address 0x0 are considered as not accessible, this should give (gdb) monitor get_vbits 0x0 10 ________ ________ ____ Address 0x0 len 10 has 10 bytes unaddressable for both the C application and the pascal application. If the bytes are not addressable and then the access syscall still SEGV, then the mystery deepens further : we need then to debug the Valgrind code that handles the VA bits to check the ascii character string. But if the address 0x0 is considered as addressable, then the best is to put breakpoints at regular places in the pascal application, and see at what points Valgrind starts to consider this address as accessible. Maybe there are some client requests changing the addressibility ? (to find this, an laternative solution is to run with more trace enabled e.g. valgrind -v -v <your pascal app> |& grep request: -- You are receiving this mail because: You are watching all bug changes.
