Ubuntu

FTBFS on i386 in quantal

Reported by Michael Terry on 2012-07-27
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SDL_gfx
Unknown
Unknown
libsdl-perl (Ubuntu)
Undecided
Unassigned
sdlgfx (Debian)
Fix Released
Unknown
sdlgfx (Ubuntu)
Undecided
Unassigned

Bug Description

libsdl-perl fails on i386 in quantal due to a test failure:

# Failed test 'MMX_detect (MMX is same as at start)'
# at t/gfx_imagefilter.t line 53.
# got: '1'
# expected: '0'
# Looks like you failed 1 test of 8.
t/gfx_imagefilter.t .............
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/8 subtests

Which is really a failure in sdlgfx's SDL_imageFilterMMXdetect call, which seems to be bogus? It uses a function _cpuFlags() written in assembly that does not seem to do what it should. Specifically, multiple calls to SDL::GFX::ImageFilter::MMX_detect() seem to alternate between "on" or "off" by itself.

Its code is:

 asm volatile ("pusha \n\t" "mov %1, %%eax \n\t" /* request feature flag */
  "cpuid \n\t" /* get CPU ID flag */
  "mov %%edx, %0 \n\t" /* move result to mmx_bit */
  "popa \n\t":"=m" (flags) /* %0 */
  :"i"(0x00000001) /* %1 */
  );

And when I write a test program, whether that assembly happens to be inside a function or not affects its output. Which seems bad. The following assembly that I found online [1] seems more robust:

#define cpuid(func,ax,bx,cx,dx)\
 __asm__ __volatile__ ("cpuid":\
 "=a" (ax), "=b" (bx), "=c" (cx), "=d" (dx) : "a" (func));
int a, b, c, d;
cpuid(1, a, b, c, d);

But I don't know enough assembly to propose a patch to the original code or explain why it is failing.

[1] http://softpixel.com/~cwright/programming/simd/cpuid.php

Steve Langasek (vorlon) wrote :

Disassembly of the _cpuFlags function on i386:

Dump of assembler code for function _cpuFlags:
=> 0xf7425030 <+0>: sub $0x10,%esp
   0xf7425033 <+3>: pusha
   0xf7425034 <+4>: mov $0x1,%eax
   0xf7425039 <+9>: cpuid
   0xf742503b <+11>: mov %edx,0xc(%esp)
   0xf742503f <+15>: popa
   0xf7425040 <+16>: mov 0xc(%esp),%eax
   0xf7425044 <+20>: add $0x10,%esp
   0xf7425047 <+23>: ret

The problem here is that popa modifies the stack pointer, so at +16 when we try to copy back off the stack into %eax, we're copying from the wrong place - pulling an arbitrary value off the stack.

I've prepared a patch for sdlgfx that appears to correct this.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package sdlgfx - 2.0.23-1ubuntu1

---------------
sdlgfx (2.0.23-1ubuntu1) quantal; urgency=low

  * debian/patches/wrong-cpuid-mmx-detection.patch: fix mmx cpuid
    detection. Closes: #663514, LP: #1029981.
 -- Steve Langasek <email address hidden> Tue, 31 Jul 2012 01:21:22 -0700

Changed in sdlgfx (Ubuntu):
status: New → Fix Released
Steve Langasek (vorlon) on 2012-07-31
Changed in libsdl-perl (Ubuntu):
status: New → Invalid
affects: libsdl-perl (Debian) → sdlgfx (Debian)
Changed in sdlgfx (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.