Testing segfaults on non-linux architectures

[ghisvail]

Following the recent introduction of globjects to Debian, packages have been built for various architectures. The status of the builds is summarized here.

I am wondering why testing for GNU Hurd and kFreeBSD fails, whilst succeeding for their x86 counterparts. Is there anything fundamentally non-portable in the globjects codebase?

Here is the relevant part of the log:

cd /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/source/tests && ../../globjects-test --gtest_output=xml:gtests-globjects-test.xml
[==========] Running 10 tests from 3 test cases.
[----------] Global test environment set-up.
[----------] 4 tests from ref_ptr_test
[ RUN      ] ref_ptr_test.DeletesItsReferenced
Segmentation fault

[scheibel]

Thanks for reporting, we'll have a look at it. I hope we find an error by thoroughly looking at our code as we don't have access to any GNU Hurd or kFreeBSD to actually start a debugger.

[ghisvail]

Indeed, just check for the obvious things. If nothing stands out, then I'll leave the investigation up to potential porters.

[pkarasev3]

I get failures like this in Windows 10 (minGW and Cygwin shells + gtest). Preliminary debugging indicates something is being used after deletion during cleanup of objects in notification chain.

    globjects.dll!globjects::IDTrait::id() Line 67  C++
    globjects.dll!globjects::Object::id() Line 50   C++
    globjects.dll!globjects::Program::detach(globjects::Shader * shader) Line 144   C++
    globjects.dll!globjects::Program::~Program() Line 75    C++

[pkarasev3]

Seems like it's "user error" but could be more obvious in the API/internals... explicitly clearing out std::unique_ptr in a canonical order fixed my instance of segfault:

ShaderProgramHolder::~ShaderProgramHolder()
{
    g_programPipeline.reset();    
    g_fragmentProgram.reset();
    g_vertexProgram.reset();        
}

Otherwise, the destructor of programPipeline will refer to already destroyed shader programs (as raw invalid pointers)

[scheibel]

I fixed the deletion a while ago but somehow there are still some users on differing platforms experiencing errors during Program deletion. We'll investigate.

[pkarasev3]

Specifically it's when a pipeline instance is destroyed after the programs that were added to it at startup. Perhaps using std::weak_pointer & std::shared_ptr would help?

[ghisvail]

Just a heads-up, this issue is still happening with 1.1.x. The segfaults are happening to non-Linux kernel builds, so I updated the title accordingly.

See: https://buildd.debian.org/status/logs.php?pkg=globjects&ver=1.1.0-1

[scheibel]

Thanks for the update, although we're still unsure when to tackle this.

[scheibel]

Unfortunately, globjects has currently no meaningful tests. However, this renders this issue void.