View Issue Details

IDProjectCategoryView StatusLast Update
0019269FPCCompilerpublic2011-05-03 17:16
ReporterkodaAssigned ToJonas Maebe 
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
PlatformIntel x86_64OSMac OS XOS Version10.7
Product VersionProduct Build 
Target VersionFixed in Version2.6.0 
Summary0019269: Opengl calls result in a crash (memory corrupted?)
DescriptionHello,
under the upcoming Mac OS X 10.7 no freepascal program using opengl are able to run.

For example trying to open Hedgewars engine results in the backtrace i posted under "Additional Information".
This bug has been confirmed also by an Apple engineer who provided a simple test program that triggers the error (attached).
Additional InformationHere is the backtrace for my program


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000005075b80e4
0x0000000107c2d402 in glColor4ub_Exec ()
(gdb) bt
#0 0x0000000107c2d402 in glColor4ub_Exec ()
0000001 0x000000010010815c in URENDER_TINT$BYTE$BYTE$BYTE$BYTE ()
0000002 0x0000000100027184 in P$HWENGINE_MAINLOOP ()
0000003 0x00007fff9247e86a in _CFXNotificationPost ()
0000004 0x00007fff9110b01b in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
0000005 0x00007fff890cb4e1 in -[NSApplication _postDidFinishNotification] ()
0000006 0x00007fff890cb26e in -[NSApplication _sendFinishLaunchingNotification] ()
0000007 0x00007fff892f5f66 in -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] ()
0000008 0x00007fff89195045 in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
0000009 0x00007fff924c5ad1 in -[NSObject performSelector:withObject:withObject:] ()
0000010 0x00007fff9119fb06 in __-[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_1 ()
0000011 0x00007fff91142c22 in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
0000012 0x00007fff91142ab0 in _NSAppleEventManagerGenericHandler ()
0000013 0x00007fff914e62fc in aeDispatchAppleEvent ()
0000014 0x00007fff914e61da in dispatchEventAndSendReply ()
0000015 0x00007fff914e60ce in aeProcessAppleEvent ()
0000016 0x00007fff92062d41 in AEProcessAppleEvent ()
0000017 0x00007fff8909d5a1 in _DPSNextEvent ()
0000018 0x00007fff8909cc5c in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
0000019 0x00007fff89061684 in -[NSApplication run] ()
0000020 0x0000000100026b01 in main ()
TagsNo tags attached.
Fixed in Revision17388
FPCOldBugId
FPCTarget
Attached Files
  • atest.pas (994 bytes)
    program atest;
    uses GL, GLU, GLUT;
    
    var lastTint: Longword;
    //var vr: Longword;
    //var vg: Longword;
    //var vb: Longword;
    //var va: Longword;
    
    procedure Tint(r, g, b, a: Byte); inline;
        var nc: Longword;
    begin
        nc:= (a shl 24) or (b shl 16) or (g shl 8) or r;
        if nc = lastTint then
            exit;
        glColor4ub(r, g, b, a);
        lastTint:= nc;
    end;
    
    procedure Tint(c: Longword); inline;
    begin
        Tint(((c shr 24) and $FF), ((c shr 16) and $FF), (c shr 8) and $FF, (c and $FF))
    end;
    
    procedure Display; cdecl;
    begin
        glClearColor(0,0,0,1);
        glClear(GL_COLOR_BUFFER_BIT);
    //    Tint(vr, vg, vb, va);
    //    glColor4ub(vr, vg, vb, va);
        glColor4ub($FF, $FFDECECE, $FF, $FF);
        glutSwapBuffers;
    end;
    
    begin
    //    vr := $FF;
    //    vg := $FFDECECE;
    //    vb := $FF;
    //    va := $FF;
        glutInit(@argc, argv);
    
        glutInitDisplayMode(GLUT_RGB or GLUT_DOUBLE);
        glutInitWindowSize(500, 500);
        glutCreateWindow('atest');
        glutDisplayFunc(@Display);
    
        glutMainLoop;
    end. 
    
    atest.pas (994 bytes)
  • freepascal.txt (1,647 bytes)
    Thanks for getting back to me on this.
    
    From looking at the engineering bug diagnosis, this is what I found:
    
    -----------------------
    
    The app is using Pascal (FreePascal) OGL bindings to call into GL (specifically glColor4ub)
    
    I have develed into this further and its looking like a bug in FreePascal (the downloadable pascal compiler)
    Attached is the dinkiest GL using pascal program I could come up with (man I totally never used pascal before) that exhibits this issue.
    
    In order to repro this issue using the attached pascal file either...
    Download and install FreePascal and run
        ppcx64 atest.pas && ./atest
    Or simply run the attached atest binary
    
    Since this is an issue with the FreePascal compiler that will REQUIRE HedgeWars to rebuild.
    
    NOTE: this was not a problem with GCC as GCC we truncate the bytes in 64-bit and fix/mask this problem.
    
    -----------------------
    
    Other info:
    
    It's the responsibility of the caller to make sure the high bits don't contain junk. Take a simple example:
    
    extern void foo(unsigned char);
    
    void t(unsigned char a, unsigned char b) {
     unsigned char c = a + b;
     foo(c);
    }
    
    Compile with llvm to bitcode file:
    define void @t(i8 zeroext %a, i8 zeroext %b) nounwind ssp {
    entry:
     %add = add i8 %b, %a
     tail call void @foo(i8 zeroext %add) nounwind
     ret void
    }
    
    The zeroext before arguments %a and %b means the input arguments have been zero-extended from i8 to 32-bit.
    
    Compile the code with gcc-4.2:
           addl    %edi, %esi
           movzbl  %sil, %edi
           jmp     _foo
    
    You see 't' does not truncate the value but it zero extend the low 8 bits before passing the value to foo.
    
    -----------------------
    
    
    freepascal.txt (1,647 bytes)

Activities

2011-04-30 12:30

 

atest.pas (994 bytes)
program atest;
uses GL, GLU, GLUT;

var lastTint: Longword;
//var vr: Longword;
//var vg: Longword;
//var vb: Longword;
//var va: Longword;

procedure Tint(r, g, b, a: Byte); inline;
    var nc: Longword;
begin
    nc:= (a shl 24) or (b shl 16) or (g shl 8) or r;
    if nc = lastTint then
        exit;
    glColor4ub(r, g, b, a);
    lastTint:= nc;
end;

procedure Tint(c: Longword); inline;
begin
    Tint(((c shr 24) and $FF), ((c shr 16) and $FF), (c shr 8) and $FF, (c and $FF))
end;

procedure Display; cdecl;
begin
    glClearColor(0,0,0,1);
    glClear(GL_COLOR_BUFFER_BIT);
//    Tint(vr, vg, vb, va);
//    glColor4ub(vr, vg, vb, va);
    glColor4ub($FF, $FFDECECE, $FF, $FF);
    glutSwapBuffers;
end;

begin
//    vr := $FF;
//    vg := $FFDECECE;
//    vb := $FF;
//    va := $FF;
    glutInit(@argc, argv);

    glutInitDisplayMode(GLUT_RGB or GLUT_DOUBLE);
    glutInitWindowSize(500, 500);
    glutCreateWindow('atest');
    glutDisplayFunc(@Display);

    glutMainLoop;
end. 
atest.pas (994 bytes)

Jonas Maebe

2011-04-30 12:42

manager   ~0047922

I cannot do anything about this since I don't have access to Mac OS X 10.7 previews. Additionally, Mac OS X 10.7 is still under NDA afaik, so I don't think you're even allowed to publicly post about this except for on Apple's private forums.

koda

2011-04-30 15:57

reporter   ~0047928

posting about my own stacktrace? you must be joking :)
at any rate I got permission for using the contents of our emails so it's fine.

I've attached one of the emails I've exchanged with the Apple engineer (again, with his permission) that contains more technical details about the issue, maybe it will shed some light on the problem.

I'll happily test on my preview copy any patch or technical experiment to help you in fixing the problem.

2011-04-30 15:57

 

freepascal.txt (1,647 bytes)
Thanks for getting back to me on this.

From looking at the engineering bug diagnosis, this is what I found:

-----------------------

The app is using Pascal (FreePascal) OGL bindings to call into GL (specifically glColor4ub)

I have develed into this further and its looking like a bug in FreePascal (the downloadable pascal compiler)
Attached is the dinkiest GL using pascal program I could come up with (man I totally never used pascal before) that exhibits this issue.

In order to repro this issue using the attached pascal file either...
Download and install FreePascal and run
    ppcx64 atest.pas && ./atest
Or simply run the attached atest binary

Since this is an issue with the FreePascal compiler that will REQUIRE HedgeWars to rebuild.

NOTE: this was not a problem with GCC as GCC we truncate the bytes in 64-bit and fix/mask this problem.

-----------------------

Other info:

It's the responsibility of the caller to make sure the high bits don't contain junk. Take a simple example:

extern void foo(unsigned char);

void t(unsigned char a, unsigned char b) {
 unsigned char c = a + b;
 foo(c);
}

Compile with llvm to bitcode file:
define void @t(i8 zeroext %a, i8 zeroext %b) nounwind ssp {
entry:
 %add = add i8 %b, %a
 tail call void @foo(i8 zeroext %add) nounwind
 ret void
}

The zeroext before arguments %a and %b means the input arguments have been zero-extended from i8 to 32-bit.

Compile the code with gcc-4.2:
       addl    %edi, %esi
       movzbl  %sil, %edi
       jmp     _foo

You see 't' does not truncate the value but it zero extend the low 8 bits before passing the value to foo.

-----------------------

freepascal.txt (1,647 bytes)

Jonas Maebe

2011-04-30 16:27

manager   ~0047930

> posting about my own stacktrace? you must be joking :)

No, posting information about a pre-release version of Mac OS X that is only available under NDA. You may want to (re)read the NDA that covers the preview of Mac OS X 10.7 you have. I don't have it, but I assume it's similar to the ones that covered beta versions of iOS.

> I've attached one of the emails I've exchanged with the Apple engineer
> (again, with his permission) that contains more technical details about
> the issue, maybe it will shed some light on the problem.

That one in fact describes exactly what the problem is and what needs to be fixed in FPC.

koda

2011-04-30 17:25

reporter   ~0047931

If you read more carefully I didn't post any information about "pre-release version of Mac OS X", I just stated that *my* program crashes under that particular system. But I got permission anyways just to avoid the kind of (useless?) discussion you are making now.

> That one in fact describes exactly what the problem is and what needs to be fixed in FPC.

Wonderful! Would you like me to check if the fix is working?

Jonas Maebe

2011-04-30 17:42

manager   ~0047932

> If you read more carefully I didn't post any information about
> "pre-release version of Mac OS X", I just stated that *my* program
> crashes under that particular system.

That is also information about that pre-release version of Mac OS X. Just like saying that a program compiled with FPC 2.5.1 svn revision xyz crashes gives information about a pre-release version of FPC (with the difference that you don't have to sign an NDA to test FPC pre-release versions, and hence are free to publicly say what you want about that).

> But I got permission anyways just to avoid the kind of (useless?)
> discussion you are making now.

Individual Apple engineers cannot relieve you from your NDA. At best Apple's legal department or ADTS could do that. And you may think I'm being pedantic and annoying, but trust me that lawyers are way worse in both departments.

> Wonderful! Would you like me to check if the fix is working?

I have not yet fixed it, and I don't know yet when I will have time to work on it.

koda

2011-04-30 20:04

reporter   ~0047936

well maybe he gave me permission because... there was no NDA'd information in what i posted :)
but yeah, i sympathise, better safe than sorry.

anyways i'll gladly test your fix when it's ready and hope that it will be committed in the 2.4.* branch.

thanks

Jonas Maebe

2011-05-01 13:34

manager   ~0047945

The 2.4.x branch is end-of-life. 2.4.4 has been tagged and is the last release from that branch. It will no longer be maintained.

Jonas Maebe

2011-05-03 17:16

manager   ~0048004

Last edited: 2011-05-03 17:16

Some extra remarks based on the discussion going on on IRC:

* even if 2.4.4 weren't tagged/packaged yet, it couldn't be simply merged because the x86-64 parameter and function result handling has been complete rewritten in 2.6.0 (it also contained several bugs regarding passing small records containing floating point values by value) That prior change is too invasive to be merged to 2.4.x.

* as mentioned ("the 2.4.x branch is end-of-life"), 2.4.4 will be the final 2.4.x release. The next one will be 2.6.0. There is no chance for a 2.4.6, and even if there was, because of the previous point it would not include this fix.

* it's not Apple "push[ing] off responsibility for fixing it to others". It's the x86-64 ABI that requires this behaviour (and in case of Darwin/i386, the Darwin/i386 ABI), although the x86-64 ABI isn't very explicit about it. The fact that the affected FPC-generated code worked with OpenGL (or any other gcc/llvm-compiled code) on prior Mac OS X versions was pure coincidence. The test committed together with the fix also fails on Linux/x86-64 and current Mac OS X versions when compiled with prior FPC versions.

Issue History

Date Modified Username Field Change
2011-04-30 12:30 koda New Issue
2011-04-30 12:30 koda File Added: atest.pas
2011-04-30 12:42 Jonas Maebe Note Added: 0047922
2011-04-30 15:57 koda Note Added: 0047928
2011-04-30 15:57 koda File Added: freepascal.txt
2011-04-30 15:59 koda Tag Attached: OpenGL
2011-04-30 16:27 Jonas Maebe Note Added: 0047930
2011-04-30 17:25 koda Note Added: 0047931
2011-04-30 17:42 Jonas Maebe Note Added: 0047932
2011-04-30 19:30 Jonas Maebe Status new => assigned
2011-04-30 19:30 Jonas Maebe Assigned To => Jonas Maebe
2011-04-30 20:04 koda Note Added: 0047936
2011-05-01 13:34 Jonas Maebe Fixed in Revision => 17388
2011-05-01 13:34 Jonas Maebe Status assigned => resolved
2011-05-01 13:34 Jonas Maebe Fixed in Version => 2.5.1
2011-05-01 13:34 Jonas Maebe Resolution open => fixed
2011-05-01 13:34 Jonas Maebe Note Added: 0047945
2011-05-01 16:03 Jonas Maebe Tag Detached: OpenGL
2011-05-03 17:16 Jonas Maebe Note Added: 0048004
2011-05-03 17:16 Jonas Maebe Note Edited: 0048004