search

bitwiseworks / libcx

kLIBC Extension Library
GNU Lesser General Public License v2.1
11 stars 1 forks source link

libcx's wrapper for exceptq does not pass EXCEPTQ_DEBUG_EXCEPTION to exceptq for processing #103

Open StevenLevine opened 1 year ago

StevenLevine commented 1 year ago

I have a need to use DosRaiseException and EXCEPTQ_DEBUG_EXCEPTION to generate exceptq reports. Currently the libcx exception handler passes EXCEPTQ_DEBUG_EXCEPTION on with XCPT_CONTINUE_SEARCH. The preferred solution would be to let exceptq handle the exception before returning XCPT_CONTINUE_SEARCH. This would eliminate the need to load exceptq locally before raising the exception.

dmik commented 1 year ago

The thing is that LIBCx doesn't deal with EXCEPTQ any more since quite some time already. All EXCEPTQ functionality was moved to LIBCn which also does not actually install EXCEPTQ but simply calls ExceptqHandler from EXCEPTQ.DLL directly to have it generate the report from the LIBC panic function.

Which actual use case do you have? Do you want to just generate EXCEPTQ reports w/o terminating the app?

StevenLevine commented 1 year ago

Oops wrong repo. Sorry. I was aware of where the exceptq support is currently implemented.

As you suspected, the use case is a need for on demand exceptq reports. What I do now for example is:

// 2023-02-02 SHL FIXME for install/uninstall to be gone when libc

supports EXCEPTQ_DEBUG_EXCEPTION // Assume exceptq.dll already loaded by libc InstallExceptq(&reg, "DI", "exceptq loaded by zend_mm_free_heap");

fprintf(stderr, "Attempting exceptq report for pid %u(%x) tid %d\n", pid,

pid, tid); err.ExceptionNum = EXCEPTQ_DEBUG_EXCEPTION; err.cParameters = 4; err.ExceptionInfo[0] = 0; err.ExceptionInfo[1] = (ULONG)chunk->heap; err.ExceptionInfo[2] = (ULONG)heap; err.ExceptionInfo[3] = (ULONG)ptr; DosRaiseException(&err);

UninstallExceptq(&reg);

If libc's exception handler passed the EXCEPTQ_DEBUG_EXCEPTION exception on the exceptq, the install/uninstall calls would not be needed.