Source Python & Sourcemod Crash (CSGO Linux)

[Sh4d0w0561]

CSGO Linux Server

[libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: netmessages.proto
[libprotobuf FATAL google/protobuf/descriptor.cc:954] CHECK failed: generated_database_->Add(encoded_file_descriptor, size):

Source Python: 206
Metamod: 1.10.7-snap948
Sourcemod: 1.7.3-snap5283

[satoon101]

Thank you for posting this here! I can confirm that the crash does happen, but only on CS:GO Linux servers. Windows loads fine, and only CS:GO uses protobuf.

[Sh4d0w0561]

Will it fixed today?

[aurorapar]

Most fixes take a while to be thrown in. New releases are very seldomly
uploaded, with the github being modified leisurely as well.

On Tue, Dec 22, 2015 at 1:32 AM, Sascha notifications@github.com wrote:

Will it fixed today?

—
Reply to this email directly or view it on GitHub
#101 (comment)
.

[Sh4d0w0561]

Problem is, I use a lot of plug-ins for Source Python, so I need urgently the fix. Would it be possible until the end of the year?

[satoon101]

We never really give ETAs for this project, and I think it would be irresponsible to give one in this case, as well. Just know that we will try to figure this issue out and fix it as soon as we can.

[Sh4d0w0561]

Okay thank you very much

[Ayuto]

When does the error occur? On loading the plugin? Since when does your server crash?

I have never tested SP and SM together, but people have told me it's working.

[Sh4d0w0561]

Crash all times without Plugins, when sp not loaded, sourcemod works, when sp loaded, crash, same with sourcemod.

[satoon101]

After a bit of testing, the error only seems to happen when SourceMod is loaded after Source.Python (or possibly simultaneously).

I placed plugin_load "addons/source-python" in the autoexec.cfg file, and it still crashed. But when I moved that to the server.cfg file, the crashing stopped.

I also tried just loading MetaMod and Source.Python normally, then loading SourceMod through meta load. However, it did not seem to fully load SourceMod, as only one item showed in meta list instead of all three.

So, for now, the "fix" is to remove the source-python.vdf file from your server and add plugin_load "addons/source-python" to your server.cfg file. I am not convinced that this issue doesn't actually lie with SourceMod, not Source.Python. Or, at least one of its parts that gets loaded when loaded directly through the .vdf by MetaMod. But, for now, we will leave this issue as active.

@xXAuroraXx - I just noticed you said "New releases are very seldomly
uploaded". We don't do releases at all anymore, since we have our buildbot setup. Anytime the master branch is pushed to, the buildbot creates a new build.

[Sh4d0w0561]

Thank you, the fix is working, great job ;)

[asherkin]

Source.Python is somehow exporting the protobuf symbols as global, which is causing issues if SourceMod gets loaded after Source.Python (as the dynamic loader uses the exported copy of Source.Python's instead of the copy included in SourceMod.)

$ find . -iname '*.so' -print0 | xargs -0 nm -CA | grep static_descriptor_initializer_netmessages_2eproto_
./source-python/source-python/bin/core.so:00c5d524 B static_descriptor_initializer_netmessages_2eproto_
./sourcemod/bin/sourcemod.2.csgo.so:0031b964 b static_descriptor_initializer_netmessages_2eproto_

B = global, b = local.

[Ayuto]

Thanks for the hint! Unfortunately, this doesn't seems to be the issue, because if I compile our core.so with "-fvisibility=hidden" the protobuf symbol is local, but the crash still happens.

[asherkin]

@Ayuto I think it's probably part of the issue, but yeah, likely not the whole shebang. Was at work and didn't have a whole lot of time, but I'll try get a chance this weekend to work out how to compile S.P and see if I can't eek out a fix.

[psychonic]

I believe that the issue is that the symbols for libprotobuf itself are being exported (in both SM and S.P). That is likely causing a similar issue to what @asherkin described, where one ends up using the other's copy of libprotobuf, both trying to register the same proto names.

-fvisibility doesn't affect symbols from static libraries. I was able to cull these in SM by adding "-Wl,--exclude-libs,ALL" to our linker flags. It removes visibility for all symbols from all linked static libraries, not affecting our explicit exports.

I'm not sure how to add this in CMake so I wasn't able to do a true test yet with both SM and S.P relinked and loaded without all of the extraneous exports.