User forums > Using Code::Blocks
Huge problem with Code::Blocks installation
oBFusCATed:
--- Quote from: codeks on August 12, 2021, 12:54:42 pm ---It compiles in codeblocks but there is some sort of a runtime problem when I try to launch the executable. When I try to launch it from terminal, it just hangs.
Only lead I have is the cachegrind error telling me the shared library isn't linked, although it is. That and, Valgrind shows a stack error.
--- End quote ---
cachegrind is not a debugger. If it hangs, meaning being stuck you're supposed to use a debugger. Attach it to the executable by pid and it will hopefully tell you where the process is stuck.
codeks:
--- Quote from: Miguel Gimenez on August 12, 2021, 01:10:28 pm ---The libwxcode_gtk3u_freechart-3.1.so.0 must be in the library search path. Usually calling make install does this, but you can do it manually, see the shared libraries howto
--- End quote ---
I've added a copy of libwxcode_gtk3u_freechart-3.1.so.0 to usr/lib/
--- Quote from: oBFusCATed on August 12, 2021, 01:12:04 pm ---cachegrind is not a debugger. If it hangs, meaning being stuck you're supposed to use a debugger. Attach it to the executable by pid and it will hopefully tell you where the process is stuck.
--- End quote ---
I get this error when I try to do it:
--- Code: ---Starting debugger: /usr/bin/gdb -nx -fullname -quiet
Setting SHELL to '/bin/sh'
done
Setting breakpoints
Attaching to program with pid: 2590
Debugger name and version: GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Attaching failed: Could not attach to process. If your uid matches the uid of the target
Attaching to process 2590
Debugger finished with status 0
--- End code ---
Now, it finds the shared library but it still hangs. When I run Valgrind memcheck I get a result of which I took a picture and attached to this post. There seems to be a conflict with freechart and wxWidgets of some sort.
Cachegrind gives me a segment overflow error:
--- Code: ---==6862== brk segment overflow in thread #1: can't grow to 0x4842000
==6862== (see section Limitations in user manual)
==6862== NOTE: further instances of this message will not be shown
==6862==
==6862== Process terminating with default action of signal 15 (SIGTERM)
==6862== at 0x738D376: pthread_cond_wait@@GLIBC_2.3.2 (futex-internal.h:183)
==6862== by 0xE8E2D5A: ??? (in /usr/lib/x86_64-linux-gnu/openblas-pthread/libblas.so.3)
==6862== by 0x7386608: start_thread (pthread_create.c:477)
==6862== by 0x5DA8292: clone (clone.S:95)
==6862==
==6862== I refs: 947,650,560
==6862== I1 misses: 373,529
==6862== LLi misses: 31,625
==6862== I1 miss rate: 0.04%
==6862== LLi miss rate: 0.00%
==6862==
==6862== D refs: 367,911,521 (263,502,989 rd + 104,408,532 wr)
==6862== D1 misses: 34,850,952 ( 34,075,546 rd + 775,406 wr)
==6862== LLd misses: 1,011,794 ( 589,787 rd + 422,007 wr)
==6862== D1 miss rate: 9.5% ( 12.9% + 0.7% )
==6862== LLd miss rate: 0.3% ( 0.2% + 0.4% )
==6862==
==6862== LL refs: 35,224,481 ( 34,449,075 rd + 775,406 wr)
==6862== LL misses: 1,043,419 ( 621,412 rd + 422,007 wr)
==6862== LL miss rate: 0.1% ( 0.1% + 0.4% )
cachegrind.out.6862
--- End code ---
Can I let it grow to the size that it wants so it works and doesn't hang?
codeks:
Update: I've ran the project in Codeblocks GDB with full debug log. Attached here are the findings.
It looks as if Basler library could be the problem but the stack is traced even before that.
I would appreciate some direction with this.
oBFusCATed:
The library is throwing an exception. This seems to be an initialize call probably suggest that it does this during loading.
You'll have to study its source code. Install symbols.
If this is a binary distro and you've installed from a package them most probably there is a package which provides symbols for the library. If you've build from source you'll have to rebuild it.
There is an option in the debugger settings to break every time the binary executes a throw in c++. This might also help shed some light where the problem is coming from.
Navigation
[0] Message Index
[*] Previous page
Go to full version