I'm not sure if it help, but changing:
protected function newFormatter() {
    return new $className;
}

to 
protected function newFormatter() {
    return new Compressed;
}

seems to solve the issue, but it might be unrelated...

Just to be sure: are there Xdebug and file_cache(_fallback)
involved?

Xdebug is disabled when this crash happens.

Here is the phpinfo() related to opcache:

opcache.blacklist_filename	no value
opcache.consistency_checks	0
opcache.dups_fix	Off
opcache.enable	On
opcache.enable_cli	Off
opcache.enable_file_override	Off
opcache.error_log	no value
opcache.file_cache	no value
opcache.file_cache_consistency_checks	1
opcache.file_cache_fallback	1
opcache.file_cache_only	0
opcache.file_update_protection	2
opcache.force_restart_timeout	60
opcache.interned_strings_buffer	8
opcache.log_verbosity_level	1
opcache.max_accelerated_files	8192
opcache.max_file_size	0
opcache.max_wasted_percentage	5
opcache.memory_consumption	512
opcache.mmap_base	no value
opcache.opt_debug_level	0
opcache.optimization_level	0xfffffbbf
opcache.preferred_memory_model	no value
opcache.protect_memory	0
opcache.restrict_api	no value
opcache.revalidate_freq	10
opcache.revalidate_path	Off
opcache.save_comments	1
opcache.use_cwd	On
opcache.validate_permission	Off
opcache.validate_timestamps	On

When file_cache is enabled, and you switch Xdebug on and off,
crashes are to be expected.  That issue has already been reported
as bug #75886.

Ah, but file_cache is not enabled in your case!

Can you please try with a recent PHP version on Windows, and
provide a *debug* backtrace, see
<https://bugs.php.net/bugs-generating-backtrace-win32.php>.

I didn't originally used xdebug and xdebug was only on a single server installed. I was able to reproduce this crash on 3 different server and on two xdebug was not installed. So I do not think it is xdebug related. 

If I added opcache_reset() to my index.php it was good all the time. After removed, it crashed.

Thanks for the further info!

Can you please try with a recent PHP version on Windows, and
provide a *debug* backtrace, see
<https://bugs.php.net/bugs-generating-backtrace-win32.php>.

Can you download it from here? Is it contains what you need?

https://www.dropbox.com/s/qr612f6mkyb14pc/MultipleDumps_MultipleRules.mht?dl=1

Thanks for the analysis report using PHP 7.3.17!  It contains the
following slightly different backtrace (unfortunately, again
without line numbers, but these might not be that helpful anyway):

php7ts!object_and_properties_init+d 
php7ts!ZEND_NEW_SPEC_VAR_UNUSED_HANDLER+40 
php7ts!execute_ex+5f 
php7ts!zend_call_function+2d0 
php7ts!zif_call_user_func_array+da 
php7ts!ZEND_DO_FCALL_BY_NAME_SPEC_RETVAL_UNUSED_HANDLER+ac 
php7ts!execute_ex+5f 
php7ts!zend_execute+1a8 
php7ts!zend_execute_scripts+b9 
php7ts!php_execute_script+261 
php7apache2_4!php_handler+591 

Anyhow, assuming that the OPcache instance isn't shared across
different PHP configurations, it looks like some combinations of
optimizations are not properly supported, which may result in
segfaults (likely trying to read offsets of NULL).

@roland, I suggest to stick with one of the working optimization
levels or just the default (0x7FFEBFFF).

I can't do anything about this without a way to reproduce.

The only suggestion I have is to make sure that the optimization level is masked with 0xfffeffff, which disables an unsafe (in the sense of "can crash" rather than "can cause misbehavior") optimization, though I doubt that is the actual cause.

Good news! I was able to create a reduced test case where this bug happens. Could you verify that the crash happens for you too?

https://www.dropbox.com/s/3jp5dzyfzmurxcc/php-bug-79535.zip?dl=1

Run index.php

The desired output: html{padding:0;}Hello World


If you open LessCompiler.php

and replace
    protected function newFormatter() {

        $className = Compressed::class;

        return new $className;
    }

with 

    protected function newFormatter() {

        return new Compressed();
    }

It will work fine. Also when you invalidate opcode cache for LessCompiler.php, then it works for the first load and every other try crashes.

Can confirm that the test case crashes at opcache.optimization_level=0xfffffaaf (but not at the default level).

Minimal:

function create() {
    $name = stdClass::class;
    return new $name;
}
var_dump(create());

with -d opcache.optimization_level=0x000000a0 (only SCCP)

==9022== Conditional jump or move depends on uninitialised value(s)
==9022==    at 0xADEAEF: ZEND_FETCH_CLASS_SPEC_UNUSED_CONST_HANDLER (zend_vm_execute.h:31745)
==9022==    by 0xB096C8: execute_ex (zend_vm_execute.h:58853)
==9022==    by 0xB0B8B1: zend_execute (zend_vm_execute.h:60939)
==9022==    by 0xA2FD73: zend_execute_scripts (zend.c:1568)
==9022==    by 0x99562D: php_execute_script (main.c:2639)
==9022==    by 0xB0E6C3: do_cli (php_cli.c:997)
==9022==    by 0xB0F8F5: main (php_cli.c:1393)

Has something to do with the FETCH_CLASS cache slot.