unreachable program point: mime_content_type()

[chongwick]

Description

The following code:

<?php
var_dump(mime_content_type('./..'));
?>

Resulted in this output:

/home/dan/php-src/main/streams/plain_wrapper.c:290:4: runtime error: execution reached an unreachable program point

PHP Version

8.4.1

Operating System

No response

[cmb69]

Apparently, the following assertion is hit:

php-src/main/streams/plain_wrapper.c

Line 290 in 0454901

ZEND_ASSERT(zend_lseek(self->fd, 0, SEEK_CUR) == 0);

I cannot reproduce on Windows, probably due to

php-src/ext/fileinfo/fileinfo.c

Lines 393 to 400 in 0454901

	#ifdef PHP_WIN32
	if (php_stream_stat_path_ex(buffer, 0, &ssb, context) == SUCCESS) {
	if (ssb.sb.st_mode & S_IFDIR) {
	ret_val = mime_directory;
	goto common;
	}
	}
	#endif

[nielsdos]

This doesn't reproduce on my system (Linux). What OS did you use, and what configuration options did you use? I tried debug builds with both GCC and Clang, and also tried a release build with GCC.

[cmb69]

It could also be helpful to see the stack backtrace.

[chongwick]

@nielsdos This is the release version of 8.4.1 with only the "--enable-undefined-sanitizer" option on Ubuntu 22.04. Oddly, this only seems to trigger inside of a Singularity container.
@cmb69 I have a stupid question... how?

[nielsdos]

Can you please retry on the last PHP-8.4 branch with a debug build and UBSAN?
You can then enable UBSAN stacktraces using an environment variable. I.e. export UBSAN_OPTIONS="print_stacktrack=true"

[chongwick]

8.4.2 ubsan debug:
ubsanphp842: /home/dan/php-src/main/streams/plain_wrapper.c:290: _php_stream_fopen_from_fd: Assertion `lseek(self->fd, 0, 1) == 0' failed.
Aborted (core dumped)

(There was no further output from stack trace)

[cmb69]

The only way this assertion could be triggered is that either lseek(2) fails (returns -1), or that the stream is not already zero-positioned. Neither should happen.

Anyhow, I don't think this is particularly related to ext/fileinfo; the following should likely behave the same:

<?php
var_dump(fopen('./..', "r"));

[chongwick]

It does. Also, var_dump() is not necessary in either case.

[nielsdos]

The container that @chongwick is probably crucial. Likely some sort of security mechanism is preventing seeking on that.

[chongwick]

@nielsdos I would say not the container rather the cluster.