Difference between Debug and Release

[empirefox]

Hi vsimon

I came across a problem which took me 3 weeks to find what code always cause segfault. Though i have work hard on it, i only found the debug and release versions are different and i still don't know what the diff is. Finally i build a simple test here and i cannot move forward one step:

#include <memory>
#include <iostream>
#include "webrtc/base/thread.h"
#include "talk/media/base/videocapturer.h"

using namespace std;
using cricket::VideoCapturer;

class GangVideoCapturer: public VideoCapturer {
public:
    GangVideoCapturer() {
    }
    cricket::CaptureState Start(const cricket::VideoFormat& capture_format) override {
        return cricket::CS_STOPPED;
    }
    void Stop() override {
    }
    bool IsRunning() override {
        return false;
    }
    bool IsScreencast() const override {
        return false;
    }
    bool GetPreferredFourccs(std::vector<uint32>* fourccs) override {
        return true;
    }
};

void run() {
    cout << "run start" << endl;
    VideoCapturer* capture = new GangVideoCapturer();
    cout << "create capturer ok" << endl;
    delete capture;
    cout << "delete capturer ok" << endl;
}

int main(int argc, char **argv) {
    run();
    cout << "quit" << endl;
}

Log when using debug lib:

make all 
Building file: ../main.cc
Invoking: GCC C++ Compiler
g++ -std=c++0x -DWEBRTC_POSIX -DPOSIX -I"/home/savage/git/webrtcbuilds" -O3 -g3 -Wall -c -fmessage-length=0 -fno-rtti `pkg-config --cflags libssl` -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cc"
Finished building: ../main.cc

Building target: ffmpeg-wrap-test
Invoking: GCC C++ Linker
g++  ./main.o   -lwebrtc_full -L/home/savage/soft/webrtc/webrtc-linux64/lib/Debug `pkg-config --libs libssl` -lstdc++ -ldl -pthread -o "ffmpeg-wrap-test"
Finished building target: ffmpeg-wrap-test

run start
create capturer ok
delete capturer ok
quit

Log when using release lib:

make all 
Building file: ../main.cc
Invoking: GCC C++ Compiler
g++ -std=c++0x -DWEBRTC_POSIX -DPOSIX -I"/home/savage/git/webrtcbuilds" -O3 -g3 -Wall -c -fmessage-length=0 -fno-rtti `pkg-config --cflags libssl` -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cc"
Finished building: ../main.cc

Building target: ffmpeg-wrap-test
Invoking: GCC C++ Linker
g++  ./main.o   -lwebrtc_full -L/home/savage/soft/webrtc/webrtc-linux64/lib/Release `pkg-config --libs libssl` -lstdc++ -ldl -pthread -o "ffmpeg-wrap-test"
Finished building target: ffmpeg-wrap-test

run start
create capturer ok

The gdb info when using release lib:

Thread #1 [ffmpeg-wrap-tes] 15049 [core: 4] (Suspended : Signal : SIGSEGV:Segmentation fault)   
    __GI___libc_free() at malloc.c:2,933 0x7ffff7048872 
    deallocate() at new_allocator.h:110 0x4083fe    
    deallocate() at alloc_traits.h:383 0x4083fe 
    _M_deallocate() at stl_vector.h:178 0x4083fe    
    ~_Vector_base() at stl_vector.h:160 0x4083fe    
    ~vector() at stl_vector.h:425 0x4083fe  
    ~RollingAccumulator() at rollingaccumulator.h:33 0x4083fe   
    cricket::VideoCapturer::~VideoCapturer() at videocapturer.h:144 0x4083fe    
    ~GangVideoCapturer() at main.cc:9 0x409240  
    GangVideoCapturer::~GangVideoCapturer() at main.cc:9 0x409240   
    <...more frames...> 

The gdb info of my origin code is weird(output.c is a source of ffmpeg): sometimes:

(Suspended : Signal : SIGSEGV:Segmentation fault)   
    yuv2rgb_X_c_template() at output.c:1,367 0x1010233  
    yuv2rgba32_X_c() at output.c:1,510 0x1010233    
    sigslot::lock_block<sigslot::single_threaded>::lock_block() at sigslot.h:257 0x90e006   
    sigslot::_signal_base0<sigslot::single_threaded>::disconnect_all() at sigslot.h:520 0x90cef2    
    gang::GangVideoCapturer::~GangVideoCapturer() at gangvideocapturer.cc:94 0x90826f   
    webrtc::VideoSource::~VideoSource() at 0x94e55e 
        ...............

and sometimes:

(Suspended : Signal : SIGILL:Illegal instruction)   
    yuv2422_2_c_template() at output.c:597 0x1010001    
    yuv2uyvy422_2_c() at output.c:670 0x1010001 
    0x0

Env:

g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13)

Thanks!

[vsimon]

Hi empirefox, I'm seeing the same thing with similar results in gdb in Release. No theories at the moment.

[vsimon]

One data point, when I built my usual target, which is several thousand commits behind, b8425b (revision 7625) and ran your snippet in Release, I didn't get a segfault.

./main run start create capturer ok delete capturer ok quit

[empirefox]

Seems degrading the revision is the only way now. I'll do it as a temporary solution.

[mangodan2003]

Did anyone get any further with this?

I too see this crash when linking against the Release build, not with the Debug build, not even an error reported by valgrind in the debug build - currently using 10279/a9046d0

I started making some very simple test cases instantiating single classes, the one that appears to cause the crash in a full application (rtc::RollingAccumulator) has no problem.

A basic instance of cricket::VideoCapturer however crashes. So I started building up to to a copy of this class from scratch and found that as soon as I add cricket::CoordinatedVideoAdapter I start to see crashes. indeed the following crashes :

int main(int artgc,char** argv) { cricket::CoordinatedVideoAdapter adaptor; }

I made my own copy of cricket::CoordinatedVideoAdapter, MyCoordinatedVideoAdapter, bizarrely this doesn't crash!

class MyCoordinatedVideoAdapter { ...... ......

int main(int artgc,char** argv) { MyCoordinatedVideoAdapter adaptor; }

The class definition and all the methods are exact copies form the build with only the namespaces amended where required and class name changed to be a bit more explicit on what I have done.

So now I am left scratching my head (well , actually writing this) and wonder where to look next, possibly compile and linker flags.

[mangodan2003]

Are there any special compile/link time flags needed besides those in lib//pkgconfig/libwebrtc_full.pc ?

I'm getting all kinds of odd results, so decided to try building the peerconnection_client. Sure enough this doesn't behave, linked against the Debug lib it launches, connects to server but crashes when ateempt to connect to another client at:

(common.cc:59): ../../talk/app/webrtc/videosource.cc(334): ASSERT FAILED: capturer != NULL @ Create

when linked with the Release lib it crashes as soon as hit the connect button.

The prebuilt binary works fine, not had audio connected to check that works but I get video at both ends.

By prebuilt, I mean the binary that gets built by the builder, I used the builder to build here locally rather than downloading a prebuilt zip.

[yomr]

Any solution to this problem,yet?

[amitv87]

To prevent this simply put #define NDEBUG in your code It is present in all the ninja build scripts, even the release ones

[weizhenwei]

@amitv87 ，Thank you SO MUCH， you saved my time!

[SoonyangZhang]

I meet this error in Debug version. very funny. And I follow the advice to add NDEBUG. And it works. Any body can give an explanation?