What does it mean of "a dirty c call"?

[wxk6b1203]

As stated. Logs show below.

==38617== TracerGrind-1.4, TracerGrind tracing tool
==38617== Charles Hubain
==38617== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==38617== Command: ./build/encrypt enc_table.txt 000102030405060708090a0b0c0d0e0f
==38617== 
==38617== Filtering instruction address range from 0x0000000000400000 to 0x000000000ff00000
==38617== Ooops that's a dirty c call ...
==38617== Ooops that's a dirty c call ...
^C==38617== 
==38617== Process terminating with default action of signal 2 (SIGINT)
==38617==    at 0x520BAF0: m4ri_gray_code (graycode.c:35)
==38617==    by 0x520BB64: m4ri_build_code (graycode.c:44)
==38617==    by 0x520BD15: m4ri_build_all_codes (graycode.c:64)
==38617==    by 0x520C8AD: m4ri_init (misc.c:73)
==38617==    by 0x40106C9: call_init.part.0 (dl-init.c:72)
==38617==    by 0x40107DA: _dl_init (dl-init.c:30)
==38617==    by 0x4000C69: ??? (in /lib/x86_64-linux-gnu/ld-2.23.so)
==38617==    by 0x2: ???
==38617==    by 0xFFF00056E: ???
==38617==    by 0xFFF00057E: ???
==38617==    by 0xFFF00058C: ???
==38617== 

This situation leads to an infinite loop and makes the disk crashed. (fully used)

Usage environment:

OS: ubuntu 18.04
ARCH: amd64
Valgrind version: 3.12
TraceTools: tracergrind

[doegox]

Thank you, @haxelion any idea?

[wxk6b1203]

I found that when using TracerGrind in some cases like the lib using m4ri will run for an extremely long time. Then we abandoned m4ri.

[sia72abedi]

@doegox What is the meaning of "Ooops that's a dirty c call ..."?
I'm able to retrieve the traces but I faced "Ooops that's a dirty c call ...". Could you please explain what is the meaning of this sentence?

valgrind --tool=tracergrind --output=AESTest.trace ./AesTest 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
==17360== TracerGrind-1.4, TracerGrind tracing tool
==17360== Charles Hubain
==17360== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==17360== Command: ./AesTest 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
==17360==
==17360== Ooops that's a dirty c call ...
==17360== Ooops that's a dirty c call ...
INPUT: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
OUTPUT: 69 c4 e0 d8 6a 7b 4 30 d8 cd b7 80 70 b4 c5 5a
==17360==

[doegox]

no idea, poking @haxelion

[haxelion]

@sia72abedi @doegox

Valgrind translates machine code into a mix of VEX IR instructions and ... C calls.
C calls are normally only used to insert C based instrumentation, like tracergrind does.

However sometimes Valgrind doesn't have the VEX IR translation for an instruction and uses C to try to fix it via emulation (they had SIMD emulation for a while). Since I can't instrument those, I just chose to emit this warning.

Since you're using a 4 years old Valgrind version, some recent intel instructions are probably to blame for.
Now you only have two cases and it doesn't crash so it's probably fine. But maybe you could try testing with Valgrind 3.15?

[sia72abedi]

@haxelion
I checked with 3.15. this problem still remains.

valgrind --tool=tracergrind --output=AESTest.trace ./AesTest 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
==23641== TracerGrind-1.4, TracerGrind tracing tool
==23641== Charles Hubain
==23641== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==23641== Command: ./AesTest 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
==23641==
==23641== Ooops that's a dirty c call ...
==23641== Ooops that's a dirty c call ...
INPUT: 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff
OUTPUT: 69 c4 e0 d8 6a 7b 4 30 d8 cd b7 80 70 b4 c5 5a
==23641==

[doegox]

@haxelion maybe we should rephrase the warning with sth like "Valgrind-emulated instruction detected, skipping instrumentation on that one" ?

[haxelion]

@doegox
The thing is ... I don't know for sure what each C call is for. Instruction emulation is one reason but it could be something else. Maybe we can make the message more explicit, but it's going to be hard to better document it because Valgrind itself does not document their C call usage :-/

@sia72abedi
You can try some combination of tracing option with Valgrind (see --help-debug) to try to understand where and why that C call was inserted. I'm not sure myself.

[wxk6b1203]

I think maybe this is caused by invoking procedure that link with dynamic linked library. I found that if I recompile my project with static link option, this probrem disappeared.