Opened 6 years ago

Closed 5 years ago

#8458 closed bug (fixed)

T5435_dyn_asm fails on x86_64 Linux

Reported by: jstolarek Owned by: ezyang
Priority: normal Milestone:
Component: Runtime System Version: 7.7
Keywords: Cc: simonmar
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Incorrect result at runtime Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

I keep getting failure from T5435_dyn_asm test:

make WAY=normal TEST=T5435_dyn_asm

=====> T5435_dyn_asm(normal) 2622 of 3829 [0, 0, 0]
cd ./rts && $MAKE -s --no-print-directory T5435_dyn_asm    </dev/null >T5435_dyn_asm.run.stdout 2>T5435_dyn_asm.run.stderr
Actual stdout output differs from expected:
--- ./rts/T5435_dyn_asm.stdout  2013-10-16 09:49:22.236712001 +0200
+++ ./rts/T5435_dyn_asm.run.stdout      2013-10-18 19:26:11.076223002 +0200
@@ -1,5 +1,5 @@
-initArray1
-initArray2
 ctors1
 ctors2
+initArray1
+initArray2
 success
*** unexpected failure for T5435_dyn_asm(normal)

Change History (5)

comment:1 Changed 6 years ago by rwbarton

I get this too on my old-stable Debian systems. I think it's because the system dlopen runs the sections in a different order than modern dlopen (which is the order the test expects).

comment:2 Changed 6 years ago by simonmar

Owner: changed from simonmar to ezyang

Edward, can we do anything about this?

comment:3 Changed 6 years ago by ezyang

Well, that is quite annoying, but good to know (that's why I put this in the test). I suppose there are a few things we could do. Probably the easiest thing to do is relax the test and warn users that GHCi's static loading behavior may differ from the dynamic loading behavior on certain platforms (code with both ctors and init_array ought to be quite rare). Could be a nasty gotcha if it does matter, though.

comment:4 Changed 5 years ago by ezyang

Status: newmerge
commit f8e12e2b396e0c475e1403ab8ac3fc4d63c1681e
Author: Edward Z. Yang <ezyang@cs.stanford.edu>
Date:   Wed Apr 9 02:32:21 2014 -0700

    Fix #5435, adding new test config check_stdout.
    
    check_stdout(f) allows you to override the test framework's
    diff based output checking with another mechanism.  f is
    a function which takes two arguments: the first is the
    filename containing the observed stdout, the second is the
    normaliser that would have been applied (in case you want
    to read, normalise, and then do something.)
    
    Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Dunno if we ought to bother merging this into stable, I'll flag it merge just in case.

comment:5 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

I'm not particularly inclined to merge this, FWIW, so I'm marking as closed unless someone else feels differently.

Note: See TracTickets for help on using tickets.