| Summary: | Fix 3DNOW-related crashes with baseline x86_64 CPU | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Reimar Döffinger <kde> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 3.7 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Remove 3dnow support bits from CPUID | ||
Sorry to be impatient, but I'd appreciate if someone could have a look. This is a really old issue I got finally annoyed enough about to debug (as a MPlayer/FFmpeg developer using an AMD CPU it is really annoying when valgrind crashes the program you're debugging half the time). Committed w/ extra comments, r2259. Thanks. |
Created attachment 67842 [details] Remove 3dnow support bits from CPUID Currently the CPUID values for this are based on a real CPU. Unfortunately, it is an AMD CPU. This means that CPUID claims to support 3DNOW while it actually doesn't. As a result, any program doing audio decoding with FFmpeg crashes in valgrind in x86_64 mode. Attached patch just hacks the CPUID a bit to remove the 3DNOW flags. That is not perfect since it now matches no real CPU but claiming to support a feature that will certainly crash is surely worse.