SDRPlusPlus
SDRPlusPlus copied to clipboard
AlexandreRouma
Latest Windows Build Binaries not running on OpenGL 2.1 Card
Hi, I tried the latest Windows Build Binary on my laptop with an OpenGL 2.1 Card it tries to start with a white screen and crashes? but when I compile the linux version from the master branch it runs perfect, I see that you have added OpenGL 2.1 support but does it only run on linux for the moment, Thanks
Can you run SDR++ from a terminal with the -s command line argument and send back what it logs?
Hi, Thanks for getting back to me this is the log
[2021-09-13 21:02:19.095] [info] SDR++ v1.0.4 [2021-09-13 21:02:19.097] [info] Loading config [2021-09-13 21:02:19.358] [error] Glfw Error 65543: Requested OpenGL version 3.0 , got version 2.1 [2021-09-13 21:02:19.361] [info] OpenGL 3.0 was not supported [2021-09-13 21:02:19.371] [error] Glfw Error 65542: WGL: OpenGL ES requested but WGL_ARB_create_context_es2_profile is unavailable [2021-09-13 21:02:19.372] [info] OpenGL 3.1 ES was not supported [2021-09-13 21:02:19.486] [info] Using OpenGL 2.1
and then it start's to load a white screen and crashes, my graphics card is a GeForce Go 7400 which supports OpenGL 2.1
is there really nothing else printed in the console after that? I need the full thing to know what's really going on. I doubt this has anything to do with opengl
Hi, Here is the screenshot of the command line when it crashes and another when I close the program
Ok, are you sure SDR++ has read/write file access rights where you decompressed it?
Also, make sure your graphics drivers are up to date.
I'd also be interested in the specs of the computer (CPU/GPU/RAM)
This is my screenshot of my CPU and GPU I have 4.00GB RAM (3.00GB) Usable 64bit Windows 8.1 I have tried Windows 7 and it has the same problem, The graphics driver is the latest possible the built in card is not supported anymore
How much free ram have you actually got when starting SDR++? Windows is pretty well known for hoarding a bunch of ram at startup... SDR++ needs almost 2GB last time I checked, mostly because of OpenGL and the enormous waterfall history buffer
This is how much ram I have left it seems SDR++ does not use much when trying to start up but Windows Defender eats through it and Firefox, It is just the same even when I turn off windows defender even If the physical ram ran out it should still use the pagefile ram?
I'm pretty sure I had the same problem trying to get SDR++ running on an old laptop on Linux today. The issue has been resolved in 1.04 (see #260), but for some reason, there are no binaries for 1.04. I had to build it from source. After many hurdles, I got it running on a 2010 laptop like a charm. You should ask the developer to put out binary releases with the fix, which came out 12 days after the most recent binary.
The 1.03 binary doesn't work on Linux for same reason. I had to build 1.04 from source.
If you look at the logs, he's already running 1.0.4 Also, the latest commit is always available in the automated builds.
I have actually the same issue with an old laptop on ubuntu 20.04. I will try to build it from source
SDR++ needs almost 2GB last time I checked, mostly because of OpenGL and the enormous waterfall history buffer
Depends on the FFT-size, doesn't it? I had some crashes in waterfall.cpp with 64k. But going down to 32768, it's rather stable.
Several places in that code is not checking for rawFFTs == NULL followed by a memset(rawFFTs, 0, ...);.
because those places are never called when rawFFTs is null. waterfall.init() gets called way before that. I've checked several times with valgrind and asan, it doesn't have any kind of issue
Really? When e.g. toggling off the "Display | Show Waterfall" check-button, and turning it on again, I once got this crash:
eax=00000000 ebx=009df8c4 ecx=04540000 edx=00f8a7a0 esi=009dea94 edi=00000000
eip=69bd381c esp=009de538 ebp=009de54c iopl=0 nv up ei pl nz na po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010203
VCRUNTIME140!memset+0x3c:
69bd381c f3aa rep stos byte ptr es:[edi]
The Call-stack clearly shows a memset() on a NULL-ptr (edi == 0 above and count == 10 349 204 bytes below):
VCRUNTIME140!memset(unsigned char * dst = 0x009dea94 "", unsigned char value = 0xa0 '', unsigned long count = 0x9dea94)+0x3c
sdrpp_core!ImGui::WaterFall::showWaterfall(void)+0x4f
sdrpp_core!displaymenu::draw(void * ctx = 0x00000000)+0x9f
sdrpp_core!Menu::draw(bool updateStates = false)+0x860
sdrpp_core!MainWindow::draw(void)+0x1641
sdrpp_core!sdrpp_main(int argc = 2, char ** argv = 0x00f81b28)+0x36f9
sdrpp!main(int argc = 2, char ** argv = 0x00f81b28)+0x10
sdrpp!invoke_main+0x1c
sdrpp!__scrt_common_main_seh(void)+0xfa
KERNEL32!BaseThreadInitThunk+0x19
ntdll!__RtlUserThreadStart+0x2f
ntdll!_RtlUserThreadStart+0x1b
Unsure about the value = 0xa0. This on a 32-bit version BTW.
The only way it can be null is if a malloc operation failed. (try searching for rawFFTs = and look at the only code assigning it)
I don't test on 32bit but I'm 90% sure it's the same thing and it's running out of memory. OpenGL takes a lot of memory by itself and when you add all the buffers for the DSP + the waterfall it's probably too much for 32bit windows to handle....
hi prep myself id try vars options with your graphics card using linux then access denied opengl 3.0-1 because in some cases there has been issues were i found myself unable to use open gl software graphics in windows but yet run smootlys in others alex your doing a great job mate
On Sat, Oct 2, 2021 at 2:32 PM Gisle Vanem @.***> wrote:
Really? When e.g. toggling off the "Display | Show Waterfall" check-button, and turning it on again, I once got this crash:
eax=00000000 ebx=009df8c4 ecx=04540000 edx=00f8a7a0 esi=009dea94 edi=00000000
eip=69bd381c esp=009de538 ebp=009de54c iopl=0 nv up ei pl nz na po cy
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010203
VCRUNTIME140!memset+0x3c:
69bd381c f3aa rep stos byte ptr es:[edi]
The Call-stack clearly shows a memset() on a NULL-ptr (edi == 0 above and count == 10 349 204 bytes below):
VCRUNTIME140!memset(unsigned char * dst = 0x009dea94 "", unsigned char value = 0xa0 '', unsigned long count = 0x9dea94)+0x3c
sdrpp_core!ImGui::WaterFall::showWaterfall(void)+0x4f
sdrpp_core!displaymenu::draw(void * ctx = 0x00000000)+0x9f
sdrpp_core!Menu::draw(bool updateStates = false)+0x860
sdrpp_core!MainWindow::draw(void)+0x1641
sdrpp_core!sdrpp_main(int argc = 2, char ** argv = 0x00f81b28)+0x36f9
sdrpp!main(int argc = 2, char ** argv = 0x00f81b28)+0x10
sdrpp!invoke_main+0x1c
sdrpp!__scrt_common_main_seh(void)+0xfa
KERNEL32!BaseThreadInitThunk+0x19
ntdll!__RtlUserThreadStart+0x2f
ntdll!_RtlUserThreadStart+0x1b
Unsure about the value = 0xa0. This on a 32-bit version BTW.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AlexandreRouma/SDRPlusPlus/issues/354#issuecomment-932753008, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARSQ36KZN2THX6GETCXKPMLUE4CXDANCNFSM5D4UYM3A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
(try searching for rawFFTs = and look at the only code assigning it)
I know. I put some trace-code around those places; always realloc() that fails.
Could such a huge buffer be pre-allocated at start-up instead? (based on max FFT-size etc.)
That would be a complete was of memory. The point alloc reallocating is to use less ram. If malloc works but realloc fails, it's a bug in the libc and I can't do much about it.
Hi, I wonder have you found my problem yet? I say it is most likely the crappy onboard Nvidia graphics card? I even have problems running linux on it! I have another laptop with 3GB Ram and with a intel x3100 graphics card which supports OpenGL 2.0, Under linux it supports OpenGL 2.1 and I was able to compile SDR++ and it runs perfect, the windows version however does not run, I was wondering if it is possible for you to dropdown support to OpenGL 2.0 I would love for it to run under windows aswell if it's not to much hassle, Thank you :)
in retrospect it was probably a driver issue knowing how trash anything made by nvidia is, I'll close for now.