clang-cl on Windows incorrectly compiles SEH (structured exception handling)

Bug report

Bug description:

clang-cl incorrectly handles SEH exception handling: llvm/llvm-project#62606
E.g. in

Lines 353 to 360 in 7c3692f

    
           int 
        
           safe_memcpy(void *dest, const void *src, size_t count) 
        
           { 
        
               HANDLE_INVALID_MEM( 
        
                   memcpy(dest, src, count); 
        
               ); 
        
               return 0; 
        
           }

where

cpython/Modules/mmapmodule.c

Lines 297 to 316 in 7c3692f

    
           #define HANDLE_INVALID_MEM(sourcecode)                                     \ 
        
           do {                                                                       \ 
        
               EXCEPTION_RECORD record;                                               \ 
        
               __try {                                                                \ 
        
                   sourcecode                                                         \ 
        
               }                                                                      \ 
        
               __except (filter_page_exception(GetExceptionInformation(), &record)) { \ 
        
                   assert(record.ExceptionCode == EXCEPTION_IN_PAGE_ERROR ||          \ 
        
                          record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION);        \ 
        
                   if (record.ExceptionCode == EXCEPTION_IN_PAGE_ERROR) {             \ 
        
                       NTSTATUS status = (NTSTATUS) record.ExceptionInformation[2];   \ 
        
                       ULONG code = LsaNtStatusToWinError(status);                    \ 
        
                       PyErr_SetFromWindowsErr(code);                                 \ 
        
                   }                                                                  \ 
        
                   else if (record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION) {     \ 
        
                       PyErr_SetFromWindowsErr(ERROR_NOACCESS);                       \ 
        
                   }                                                                  \ 
        
                   return -1;                                                         \ 
        
               }                                                                      \ 
        
           } while (0)

This lets test_mmap.MmapTests.test_access_violations fail for clang-cl builds on Windows,
see e.g. https://github.com/python/cpython/actions/runs/14044831663/job/39323183797?pr=131690#step:4:566.

The suggestion in llvm/llvm-project#62606 (comment) is to use EHa,

the problem is that without /EHa, the compiler assumes memory accesses don't trap

which seems wrong, and clearly is a compatibility issue wrt to MSVC.
Since Python code is compiled in C mode, EHa would seem really weird to me. Even more weird workaround: wrap the "body" (here sourcecode) in a separate function and guard that via SEH.

I've tried both workarounds and they would fix the problem.

CPython versions tested on:

3.14

Operating systems tested on:

Windows

Linked PRs

GH-131691: fix SEH for clang-cl on Windows #131730

Even more weird workaround: wrap the "body" (here sourcecode) in a separate function and guard that via SEH.

I thought we were already doing that? I tried to make sure it was designed that way (e.g. the "safe_*" functions) so that it's clear where the protection starts and ends, and we don't have to worry about any state (e.g. no calls back into Python are possible). The macro should just be to help implement those with less repetition (not my preference, but someone else was doing the PR).

But looking a little further down the llvm issue, it sounds like they just gave /EHa a slightly different meaning. So if it can be specified for Clang (I assume the ClCompile.ExceptionHandling metadata is interpreted here?) but not MSVC then it seems that should be fine.

Yeah, since SEH is also used in sqlite3.c and ctypes (and up to recently for stack checking via _alloca), let's set <ExceptionHandling>Async</ExceptionHandling> in pyproject-clangcl.props so that all source files are compiled with it: #131730

GH-131691: Fix exception handling setting for clang-cl on Windows (GH…

pythonGH-131691: Fix exception handling setting for clang-cl on Windo…

Navigation Menu

Repository navigation

clang-cl on Windows incorrectly compiles SEH (structured exception handling) #131691

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	int
	safe_memcpy(void dest, const void src, size_t count)
	{
	HANDLE_INVALID_MEM(
	memcpy(dest, src, count);
	);
	return 0;
	}

	#define HANDLE_INVALID_MEM(sourcecode) \
	do { \
	EXCEPTION_RECORD record; \
	__try { \
	sourcecode \
	} \
	__except (filter_page_exception(GetExceptionInformation(), &record)) { \
	assert(record.ExceptionCode == EXCEPTION_IN_PAGE_ERROR \|\| \
	record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION); \
	if (record.ExceptionCode == EXCEPTION_IN_PAGE_ERROR) { \
	NTSTATUS status = (NTSTATUS) record.ExceptionInformation[2]; \
	ULONG code = LsaNtStatusToWinError(status); \
	PyErr_SetFromWindowsErr(code); \
	} \
	else if (record.ExceptionCode == EXCEPTION_ACCESS_VIOLATION) { \
	PyErr_SetFromWindowsErr(ERROR_NOACCESS); \
	} \
	return -1; \
	} \
	} while (0)

clang-cl on Windows incorrectly compiles SEH (structured exception handling) #131691

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

zooba commented on Mar 24, 2025

chris-eibl commented on Mar 25, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions