Core Dump on First Start

[joshuarubin]

Just built and tried to run for the first time and immediately got a core dump (the window outline showed very briefly). I'm running wayland/sway (with a 150% scaled 4k monitor) on an amd gpu with kernel 5.12.15. This is using commit ead7ee1.

Happy to help debug this in any way possible.

Here are the logs I'm getting:

[2021-07-16 10:25:27.596] [info] SDR++ v0.3.0_beta
[2021-07-16 10:25:27.596] [info] Loading config
[2021-07-16 10:25:27.597] [warning] ConfigManager locked, waiting...
[2021-07-16 10:25:28.234] [error] Glfw Error 65544: Wayland: Focusing a window requires user interaction
[2021-07-16 10:25:28.259] [error] Glfw Error 65544: Wayland: Setting window icon not supported
[2021-07-16 10:25:28.259] [error] Failed to initialize OpenGL loader!
sdrpp: /home/jrubin/dev/SDRPlusPlus/core/src/dsp/block.h:43: void dsp::generic_block<BLOCK>::stop() [with BLOCK = dsp::Reshaper<dsp::complex_t>]: Assertion `_block_init' failed.

And here's the backtrace, but it's not particularly helpful.

#0  0x00007f9d24499d22 in raise () from /usr/lib/libc.so.6
#1  0x00007f9d24483862 in abort () from /usr/lib/libc.so.6
#2  0x00007f9d24483747 in __assert_fail_base.cold () from /usr/lib/libc.so.6
#3  0x00007f9d24492616 in __assert_fail () from /usr/lib/libc.so.6
#4  0x00007f9d256b6e26 in dsp::generic_block<dsp::Reshaper<dsp::complex_t> >::stop (this=<optimized out>)
    at /home/jrubin/dev/SDRPlusPlus/core/src/dsp/block.h:43
#5  dsp::Reshaper<dsp::complex_t>::~Reshaper (this=<optimized out>, __in_chrg=<optimized out>) at /home/jrubin/dev/SDRPlusPlus/core/src/dsp/routing.h:80
#6  0x00007f9d256beb2a in SignalPath::~SignalPath (this=0x7f9d25b53840 <sigpath::signalPath>, __in_chrg=<optimized out>)
    at /home/jrubin/dev/SDRPlusPlus/core/src/signal_path/dsp.h:7
#7  0x00007f9d2449ca8e in __cxa_finalize () from /usr/lib/libc.so.6
#8  0x00007f9d254e2d88 in __do_global_dtors_aux () from /home/jrubin/dev/SDRPlusPlus/build/core/libsdrpp_core.so
#9  0x00007ffc24882ca0 in ?? ()
#10 0x00007f9d25b671a4 in _dl_fini () from /lib64/ld-linux-x86-64.so.2

[AlexandreRouma]

Hello,

I don't know much about wayland but it seems like it can't load OpenGL. Make sure you've got a driver or software renderer that supports at least OpenGL 3.2

The assertion fail is unrelated, it's basically complaining that it had to terminate a thread without the block being initialized yet because of the OpenGL error.

[joshuarubin]

Yeah, it looks like a glew thing, but glewinfo works, so I'm looking into that.

[joshuarubin]

Looks like I'm running into nigels-com/glew#306

[joshuarubin]

I was able to get everything working by updating the code in core.cpp so that glewInit() now looks like:

  GLenum glewErr = glewInit();
  if (glewErr != GLEW_OK && glewErr != GLEW_ERROR_NO_GLX_DISPLAY) {

[AlexandreRouma]

although this can be a quick and dirty "fix" it's very bad.
If glew returns any error it shouldn't just be ignore as that will for sure cause unpredictable behavior.

[joshuarubin]

Understood, it's a known issue with glew though, doesn't seem that bad to put in temporarily as it's only allowing one very specific error to go through and the initialization is otherwise successful.

Also listed here nigels-com/glew#172 which references supertuxkart/stk-code@961ac4d.

[AlexandreRouma]

I think an issue should be opened on the glew repo to add a fix for this directly into glew.

Would avoid having to specifically check for wayland in software (because GLEW_ERROR_NO_GLX_DISPLAY is a very bad error with X11).

I'll keep this issue open until a fix comes out from glew

[nigels-com]

Try rebuilding GLEW and the application with GLEW_EGL defined.

[Cadair]

I have just run into this (on sway same as OP). It looks like some changes have been made in GLEW, but I don't understand them! What's the current status of this issue? Thanks!

[AlexandreRouma]

All of this is likely fixed in the latest nightly, reopen if not.