Protobuf: [PHP]Unable to load descriptor: out of memory

Created on 12 Dec 2019  Â·  11Comments  Â·  Source: protocolbuffers/protobuf

What version of protobuf and what language are you using?

Version: v3.11.1
Language: PHP

What operating system (Linux, Windows, ...) and version?

Linux

What runtime / compiler are you using (e.g., python version or gcc version)

PHP: 7.3.11
gcc: 5.4.0

What did you do?

When I use Grpc1::initOnce() and Grpc2::initOnce() :PHP Fatal error: Unable to load descriptor: out of memory

The demo code:
test.zip

run:php test.php

What did you expect to see

No problem

What did you see instead?

PHP Fatal error:  Unable to load descriptor: out of memory

Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs).

Anything else we should know about your project / environment

Most helpful comment

Looking at the code, this issue has to be "fixed" now.
By "fixed" I mean that the test case will now result in "duplicate symbol" error instead of "out of memory", which was definitely not true.

The "duplicate symbol" error is caused by the fact that both grpc1.proto and grpc2.proto from the test.zip above do not have a package defined, so from the point of view of Protocol Buffers both these protocols declare their symbols in global namespace, therefore messages with the same name do indeed clash with each other.

All 11 comments

You should not call initOnce by yourself. Just use constructor to create
message

On Wed, Dec 11, 2019 at 23:55 Yurun notifications@github.com wrote:

What version of protobuf and what language are you using?

Version: v3.11.1
Language: PHP

What operating system (Linux, Windows, ...) and version?

Linux

What runtime / compiler are you using (e.g., python version or gcc
version)

PHP: 7.3.11
gcc: 5.4.0

What did you do?

When I use Grpc1::initOnce() and Grpc2::initOnce() :PHP Fatal error:
Unable to load descriptor: out of memory

The demo code:
test.zip
https://github.com/protocolbuffers/protobuf/files/3954469/test.zip

run:php test.php

What did you expect to see

No problem

What did you see instead?

PHP Fatal error: Unable to load descriptor: out of memory

Make sure you include information that can help us debug (full error
message, exception listing, stack trace, logs).

Anything else we should know about your project / environment

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/protocolbuffers/protobuf/issues/7010?email_source=notifications&email_token=ABHUPZNXLSVKHPGRMRSQZNTQYHVADA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H77ECDA,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHUPZJRV6N5OLJ5TYJVYILQYHVADANCNFSM4JZ2M5SQ
.

You should not call initOnce by yourself. Just use constructor to create message
…
On Wed, Dec 11, 2019 at 23:55 Yurun @.*> wrote: What version of protobuf and what language are you using? Version: v3.11.1 Language: PHP What operating system (Linux, Windows, ...) and version? Linux What runtime / compiler are you using (e.g., python version or gcc version) PHP: 7.3.11 gcc: 5.4.0 What did you do? When I use Grpc1::initOnce() and Grpc2::initOnce() :PHP Fatal error: Unable to load descriptor: out of memory The demo code: test.zip https://github.com/protocolbuffers/protobuf/files/3954469/test.zip run:php test.php What did you expect to see No problem What did you see instead? PHP Fatal error: Unable to load descriptor: out of memory Make sure you include information that can help us debug (full error message, exception listing, stack trace, logs). Anything else we should know about your project / environment — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7010?email_source=notifications&email_token=ABHUPZNXLSVKHPGRMRSQZNTQYHVADA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H77ECDA>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHUPZJRV6N5OLJ5TYJVYILQYHVADANCNFSM4JZ2M5SQ .

Use constructor to create is still the same problem:

$a1 = new \Test1\A;
$a2 = new \Test2\A;

Have you set composer.json for GPBMetadata?

On Thu, Dec 12, 2019 at 00:00 Yurun notifications@github.com wrote:

You should not call initOnce by yourself. Just use constructor to create
message
… <#m_-8246239168261380701_>
On Wed, Dec 11, 2019 at 23:55 Yurun @.*> wrote: What version of
protobuf and what language are you using?
Version: v3.11.1 Language: PHP What
operating system (Linux, Windows, ...) and version?
Linux What runtime
/ compiler are you using (e.g., python version or gcc version)
PHP:
7.3.11 gcc: 5.4.0 What did you do? When I use Grpc1::initOnce() and
Grpc2::initOnce() :PHP Fatal error: Unable to load descriptor: out of
memory The demo code: test.zip
https://github.com/protocolbuffers/protobuf/files/3954469/test.zip
run:php test.php What did you expect to see No problem What did you
see instead?
PHP Fatal error: Unable to load descriptor: out of memory
Make sure you include information that can help us debug (full error
message, exception listing, stack trace, logs). Anything else we should
know about your project / environment
— You are receiving this because
you are subscribed to this thread. Reply to this email directly, view it on
GitHub <#7010 https://github.com/protocolbuffers/protobuf/issues/7010?email_source=notifications&email_token=ABHUPZNXLSVKHPGRMRSQZNTQYHVADA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H77ECDA>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHUPZJRV6N5OLJ5TYJVYILQYHVADANCNFSM4JZ2M5SQ
.

Use constructor to create is still the same problem:

$a1 = new \Test1\A;
$a2 = new \Test2\A;

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/protocolbuffers/protobuf/issues/7010?email_source=notifications&email_token=ABHUPZMNXXYMDV2O3MAT4UDQYHVRRA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGVZTPA#issuecomment-564894140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHUPZOYHR5KVYTIJEL3PLDQYHVRRANCNFSM4JZ2M5SQ
.

Does it also fail with previous versions?

On Thu, Dec 12, 2019 at 00:50 Paul Yang paulyang1211@gmail.com wrote:

Have you set composer.json for GPBMetadata?

On Thu, Dec 12, 2019 at 00:00 Yurun notifications@github.com wrote:

You should not call initOnce by yourself. Just use constructor to create
message
… <#m_-4553070761051010932_m_-8246239168261380701_>
On Wed, Dec 11, 2019 at 23:55 Yurun @.*> wrote: What version of
protobuf and what language are you using?
Version: v3.11.1 Language:
PHP What operating system (Linux, Windows, ...) and version? Linux What
runtime / compiler are you using (e.g., python version or gcc version)

PHP: 7.3.11 gcc: 5.4.0 What did you do? When I use Grpc1::initOnce()
and Grpc2::initOnce() :PHP Fatal error: Unable to load descriptor: out of
memory The demo code: test.zip
https://github.com/protocolbuffers/protobuf/files/3954469/test.zip
run:php test.php What did you expect to see No problem What did you
see instead?
PHP Fatal error: Unable to load descriptor: out of memory
Make sure you include information that can help us debug (full error
message, exception listing, stack trace, logs). Anything else we should
know about your project / environment
— You are receiving this because
you are subscribed to this thread. Reply to this email directly, view it on
GitHub <#7010 https://github.com/protocolbuffers/protobuf/issues/7010?email_source=notifications&email_token=ABHUPZNXLSVKHPGRMRSQZNTQYHVADA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H77ECDA>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHUPZJRV6N5OLJ5TYJVYILQYHVADANCNFSM4JZ2M5SQ
.

Use constructor to create is still the same problem:

$a1 = new \Test1\A;
$a2 = new \Test2\A;

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/protocolbuffers/protobuf/issues/7010?email_source=notifications&email_token=ABHUPZMNXXYMDV2O3MAT4UDQYHVRRA5CNFSM4JZ2M5S2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGVZTPA#issuecomment-564894140,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABHUPZOYHR5KVYTIJEL3PLDQYHVRRANCNFSM4JZ2M5SQ
.

composer.json for GPBMetadata is ok

v3.10 also has this problem

Could you provide some simple code (without your logic) to regenerate the issue?

Could you provide some simple code (without your logic) to regenerate the issue?

code:
test2.zip

run: php test.php

@Yurunsoft were you able to figure out the cause/fix for this issue?

Sorry, I only know that the problem should be in the initOnce method

I agree completely with @Yurunsoft , facing the same weird issue as pointed out by him already in a detailed way via test2.zip

I was also able to reproduce this issue and it was happening for me consistently whenever two similar proto messages with same name and structure belonging to different RPCs get instantiated, in that case the allocation of the latter one fails with out of memory error. This is applicable even when one of the proto message is the subset of other.

Changing the name along with message field names (top to bottom/nested) offered me the workaround for this.
However this is a very tedious workaround and not feasible when this issue is discovered at a later point of time when most of the code might already be live.

Please provide the fix for this, it is an issue with protobuf library.

Looking at the code, this issue has to be "fixed" now.
By "fixed" I mean that the test case will now result in "duplicate symbol" error instead of "out of memory", which was definitely not true.

The "duplicate symbol" error is caused by the fact that both grpc1.proto and grpc2.proto from the test.zip above do not have a package defined, so from the point of view of Protocol Buffers both these protocols declare their symbols in global namespace, therefore messages with the same name do indeed clash with each other.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

larribas picture larribas  Â·  48Comments

cl51287 picture cl51287  Â·  29Comments

Interfere picture Interfere  Â·  30Comments

mkosieradzki picture mkosieradzki  Â·  70Comments

laszloagardi picture laszloagardi  Â·  40Comments