Bug 724

Summary:	valgrind does not like nsc stacks on 64 bit Linux
Product:	nsc	Reporter:	Joerg <joerg.wagner>
Component:	Linux	Assignee:	Sam Jansen <sam.jansen>
Status:	RESOLVED FIXED
Severity:	normal
Priority:	P5
Version:	unspecified
Hardware:	All
OS:	All

Description Joerg 2009-10-19 09:33:28 UTC

Using stock NS-3 3.5.1 with
./waf --run tcp-nsc-zoo --command-template "valgrind --leak-check=yes --track-origins=yes --log-file=vg.log %s"

vex amd64->IR: unhandled instruction bytes: 0x15 0xFF 0xFF 0x0 0x0 0x89
==6957== valgrind: Unrecognised instruction at address 0x703d8c3.
.this might well be an valgrind issue

Workaround: Checksum calculations using plain-C variants (touching Linux headers)

Comment 1 Sam Jansen 2009-10-21 14:58:49 UTC

There is an ongoing problem with the (sometimes embedded) assembler used in the Linux code, and opcodes not being supported in Valgrind.

I don't really think this is an NSC problem; I think whenever we find these opcodes we should report them to the Valgrind team. Historically, they have been very quick to implement new opcodes.

If there is a clean way to change the checksums to the plain C version (e.g. just change the config #define's), then I'm happy to do that, otherwise I am loathe to go muddling with headers (makes upgrading harder, means we are diverting from the real code paths of Linux, etc.)

Does this seem reasonable? Leaving the bug open for now for discussion, else I'll close it in a few days.

Comment 2 Joerg 2009-10-22 02:38:29 UTC

Yes of course not touching the Linux stacks would be the best option. I am still not sure whether this problem is 64-bit related or not (have no 32bit system at the very moment to test with).

An alternative to touching the Linux stack code would be to use link-time function wrapping. However I am not sure if that works reliable on inline functions, especially in the higher -Ox modes.
I will report this issue to the Valgrind people, let's see if they can fix it on their side.
I try to get some virtual 32bit system running for ruling out this possibility, could we let this open until then?

Comment 3 Joerg 2009-10-22 08:06:42 UTC

Cannot reproduce this with NS-3 3.6 in a virtual 32 bit environment.
Issue was reported to the Valgrind bug tracker.

Comment 4 Joerg 2009-11-05 05:32:18 UTC

Valgrind people confirmed this and already have made a fix available (Valgrind Bug ID: 211410), so we can close this.