Protobuf PHP compiled library segmentation faults

[blacktek]

Hello,
I've random segfaults when using protobuf php compiled extension with google ads api.
Same issue happens with both PHP 7.4.29 and PHP 8.1.6 on
$ uname -a
Linux xxxx.it 5.4.0-100-generic #113-Ubuntu SMP Thu Feb 3 18:43:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Core was generated by `/usr/local/php81debug/bin/php /home/xxxxxxxx/domains/sf.xxxxx.it/cron/proces'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0 0x0000561648c65d07 in _zend_is_inconsistent (ht=0x0, file=0x5616496c7238 "/usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_hash.c", line=2469) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_hash.c:54

54 if ((HT_FLAGS(ht) & HASH_FLAG_CONSISTENCY) == HT_OK) {

[Current thread is 1 (Thread 0x7f3cb9586bc0 (LWP 3090694))]

(gdb) bt

#0 0x0000561648c65d07 in _zend_is_inconsistent (ht=0x0, file=0x5616496c7238 "/usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_hash.c", line=2469) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_hash.c:54

#1 0x0000561648c6dd71 in zend_hash_get_current_data_ex (ht=0x0, pos=0x24) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_hash.c:2469

#2 0x0000561648a36502 in zif_current (execute_data=0x7f3cb9217190, return_value=0x7f3cb92170e0) at /usr/local/directadmin/custombuild/php-8.1.6/ext/standard/array.c:1184

#3 0x0000561648c8e616 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_vm_execute.h:1297

#4 0x0000561648d036db in execute_ex (ex=0x7f3cb9216020) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_vm_execute.h:55756

#5 0x0000561648d08f2f in zend_execute (op_array=0x7f3cb925f3c0, return_value=0x0) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend_vm_execute.h:60123

#6 0x0000561648c51979 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/local/directadmin/custombuild/php-8.1.6/Zend/zend.c:1792

#7 0x0000561648bae644 in php_execute_script (primary_file=0x7ffc99f3f6b0) at /usr/local/directadmin/custombuild/php-8.1.6/main/main.c:2538

#8 0x0000561648dc5725 in do_cli (argc=4, argv=0x56164b7c19e0) at /usr/local/directadmin/custombuild/php-8.1.6/sapi/cli/php_cli.c:966

#9 0x0000561648dc6867 in main (argc=4, argv=0x56164b7c19e0) at /usr/local/directadmin/custombuild/php-8.1.6/sapi/cli/php_cli.c:1368

I can provide the coredump too (but it's > 200MB).

The segmentation faults only happen when using the compiled version of the library; if I include the library with Composer it's fine (but slow)

I opened the issue on the protocol buffer Forum and GoogleAds Forum, but they said it's an issue with Google APIs and not with their library:

protocolbuffers/protobuf#10113
https://groups.google.com/g/adwords-api/c/lR0AAUah0qY

Do you have any advice?

This is happening with the most recent versions fo the libraries too.

I've made tests by disabling opcache and opcache-cli, but nothing changed

Thank you

[fiboknacky]

Actually, we probably still need the protobuf team's help since it occurs in the protobuf layer.
Having said that, we need to first pinpoint what causes this down to the smallest lines of code first.

Did you run this under Docker or server? If so, could you try running it locally?
Try to remove unnecessary code and get the smallest chunk of code that can reproduce this.

[blacktek]

Hello,
I understand. The point is that this problem is totally random and not reproducible in a deterministic way.
It doesn't crash always with same report or the same account. Sometimes the segfaults happen after 3 reports, sometimes after the 15th report.
It seems related to the memory status or interaction with other extensions.

Where can we start from?

Tnx

[fiboknacky]

In that case, it's really challenging to pinpoint the cause.
Could you at least try scoping down the code as much as possible and share it with us?
In addition, we'd need to know more about how you run the reports.
Right now, it looks more like a memory issue but if you can run reports with the same date range and with the same set and order of accounts, I think we can identify the pattern a bit more easily.

Did you run this under Docker or server? If so, could you try running it locally?
And could you share this information too?

[fiboknacky]

Closing due to inactivity.