discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libobjc2 on Windows with clang 13 (crash prior to main)


From: Frederik Seiffert
Subject: Re: libobjc2 on Windows with clang 13 (crash prior to main)
Date: Thu, 17 Feb 2022 10:01:06 +0100

It might be helpful to open a GitHub issue against libobjc2 with the details of the test failures, and perhaps also a pull request upgrading the CI to use a newer Clang. Currently it gets tested against Clang 8 and 12:
https://github.com/gnustep/libobjc2/blob/master/azure-pipelines.yml
https://github.com/gnustep/libobjc2/blob/master/.cirrus.yml

@David may I ask how you’re building libobjc2 under MinGW, e.g. do you have any custom patches to make this work? My last attempts are documented here, and basically got stuck figuring out the exception handling in that environment (and they also required an LLVM patch):
https://github.com/gnustep/libobjc2/pull/190

Alternatively, if you don’t require libs-gui you could also look into switching to the MSVC toolchain, which works with the Clang version included in the latest Visual Studio 2022:
https://github.com/gnustep/tools-windows-msvc


Am 17.02.2022 um 08:37 schrieb Andreas Fink <afink@list.fink.org>:

I had issues with clang-14 and went back to clang-11 which always worked.
if you run the tests in libobj2 and/or gnustep-base they fail with clang-14 under Debian 10 & 11. And if I remember correctly, they fail before main() as in your case.
So I can imagine you run into the same issue.

David Vernon wrote on 17.02.22 01:03:
Hello all. I’m brand new to the list. I work for Keysight Technologies on Eggplant – a commercial project that uses gnustep for our Windows port. I’m having some issues, and Greg Casamento has recommended that raise them here.
 
We build on Windows using msys64 and clang. I am trying to upgrade clang to the current version (v13) and I’m pretty much stuck. I can get libobjc2 and lib-base to build, but when I run a very simple test app is crashes prior to main.
 
The test program:
#import <Foundation/Foundation.h>
#include "stdio.h"
 
#if 0
 
@interface Test : NSObject
@end
 
@implementation Test
@end
 
#endif
 
int main (void)
{
  fprintf( stderr, "Hello World\n");
  return 0;
}
 
Run it like this and all is good: it prints “Hello World”. Flip the #if 0 to #if 1, and it crashes prior to main.
 
Gdb shows this stack trace:
#0  0x00007ffe8b92a263 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x00007ffe8b8ecd24 in ntdll!memset () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00007ffe8b929111 in ntdll!RtlRegisterSecureMemoryCacheCallback ()
   from C:\Windows\SYSTEM32\ntdll.dll
#3  0x00007ffe8b855cc1 in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\Windows\SYSTEM32\ntdll.dll
#4  0x00007ffe8b855b74 in ntdll!RtlGetCurrentServiceSessionId ()
   from C:\Windows\SYSTEM32\ntdll.dll
#5  0x00007ffe8b8547b1 in ntdll!RtlFreeHeap ()
   from C:\Windows\SYSTEM32\ntdll.dll
#6  0x00007ffe89a99c9c in msvcrt!free () from C:\Windows\System32\msvcrt.dll
#7  0x00007ffe41ec8068 in +[GSBlock load] (self=<optimized out>,
    _cmd=<optimized out>) at GSBlocks.m:55
#8  0x00007ffe66e4281d in objc_send_load_message ()
   from C:\msys64\mingw64\bin\libobjc.dll
#9  0x00007ffe66e4356b in objc_resolve_class ()
   from C:\msys64\mingw64\bin\libobjc.dll
#10 0x00007ffe66e4366c in objc_resolve_class_links ()
   from C:\msys64\mingw64\bin\libobjc.dll
#11 0x00007ffe66e47e47 in __objc_exec_class ()
   from C:\msys64\mingw64\bin\libobjc.dll
#12 0x00007ffe41ec80d0 in objc_load_function ()
   from C:\msys64\mingw64\GNUstep\System\Tools\gnustep-base-1_28.dll
#13 0x00007ffe4209b9d2 in __do_global_ctors ()
    at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/gccmain.c:44
#14 0x00007ffe41ec1233 in __DllMainCRTStartup (hDllHandle=0x7ffe41ec0000,
    dwReason=1, lpreserved=0x12f5ef750)
    at C:/M/mingw-w64-crt-git/src/mingw-w64/mingw-w64-crt/crt/crtdll.c:184
#15 0x00007ffe8b849a1d in ntdll!RtlActivateActivationContextUnsafeFast ()
   from C:\Windows\SYSTEM32\ntdll.dll
#16 0x00007ffe8b89c1e7 in ntdll!LdrGetProcedureAddressEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
#17 0x00007ffe8b89bf7a in ntdll!LdrGetProcedureAddressEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
#18 0x00007ffe8b89c000 in ntdll!LdrGetProcedureAddressEx ()
   from C:\Windows\SYSTEM32\ntdll.dll
#19 0x00007ffe8b903c2a in ntdll!LdrInitShimEngineDynamic ()
   from C:\Windows\SYSTEM32\ntdll.dll
#20 0x00007ffe8b8a4cdb in ntdll!LdrInitializeThunk ()
   from C:\Windows\SYSTEM32\ntdll.dll
#21 0x00007ffe8b8a4b63 in ntdll!LdrInitializeThunk ()
   from C:\Windows\SYSTEM32\ntdll.dll
#22 0x00007ffe8b8a4b0e in ntdll!LdrInitializeThunk ()
   from C:\Windows\SYSTEM32\ntdll.dll
#23 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
 
Any ideas as to how I might proceed would be graciously appreciated.
 
Dave Vernon
Keysight Technologies 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]