I can't reproduce the bug: https://3v4l.org/omfrZ

This is going to be a problem either with your system, or some other problem we can't help with.

Please feel free to update this with a reproducible case.

This worked fine on PHP 7.2.12 on the same server. The only thing that has changed is the version of PHP that I am using.

The following code:

<?php

$x = 'This is a string';
$y = base64_encode($x);
$z = base64_decode($y);

var_dump($x) . '<br />';
var_dump($y) . '<br />';
var_dump($z) . '<br />';

Produces:

string(16) "This is a string"
string(-6072743447921604100) "

2018/12/11 13:24:05 [error] 91715#100408: *63 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 12374000625787949056 bytes) in [FILE] on line 8" while reading response header from upstream, client: [IP], server: [SERVER], request: "GET /[FILE] HTTP/1.0", upstream: "fastcgi://127.0.0.1:9000", host: "[SERVER]"

It appears the output from base64_encode() is invalid.

Base64 encoding has SIMD based implementations in 7.3, so this issue might be architecture dependent. Can you please tell me which SIMD extensions your CPU supports? In particular AVX2 and SSSE3 support would be relevant.

I pulled the following out of the system dmesg output:

CPU: Intel(R) Xeon(R) CPU E5-2630 v2 @ 2.60GHz (2600.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306e4  Family=0x6  Model=0x3e  Stepping=4
  Features=0xfa3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS>
  Features2=0xffba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND,HV>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  Structured Extended Features=0x283<FSGSBASE,TSCADJ,SMEP,ERMS>
  TSC: P-state invariant

Thanks, that should put you on the SSSE3 implementation. I just tried to force it locally, and it's working fine for me.

Not sure what could be the issue here, maybe laruence has an idea?

Also bug #77279 looks very related. In both cases we have a SIMD optimized function with FreeBSD as the operating system. Likely the same root cause.

This can be reproduced pretty quickly in a qemu-vm - I downloaded http://ftp.nl.freebsd.org/releases/VM-IMAGES/11.2-RELEASE/amd64/Latest/FreeBSD-11.2-RELEASE-amd64.qcow2.xz, uncompressed and logged in with root and ran:

# portsnap fetch extract && cd /usr/ports/lang/php73 && make install
 (select debug build, accept defaults for the rest

This will get you a debug php73 build which shows the same behavior

I can reproduce this issue on an AMD 64 supporting SSSE3, but not
AVX2, running a Vagrant bento/freebsd-11.2[1].
resolve_base64_encode() returns php_base64_encode_ssse3()[2], but
setting a breakpoint for this function is somehow ignored.

[1] <https://app.vagrantup.com/bento/boxes/freebsd-11.2>
[2] <https://github.com/php/php-src/blob/php-7.3.0/ext/standard/base64.c#L431>

Might be relevant:

    $ cc -v
    FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)

Possible work-around: Upgrade to FreeBSD 12.0.

I used freebsd-update to upgrade the same server to FreeBSD 12.0 and re-installed the same PHP73 package. Everything works as expected.

I went ahead and disabled the use of ifuncs on FreeBSD: https://github.com/php/php-src/commit/291589114aa9be899cf7d5d874c3b5bbdb35f336

We can reenable or restrict this check once we know the exact cause.